Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Wow my hello world 16f18446 got 21 downloads

Status
Not open for further replies.
Burt!! I am using an Arduino Mega and the DTR is used to pulse the reset... It has caused me soooooo much heartache.

Just check the schematic as this is done by default... When you connect serially via the USB the DTR is wobbling the reset ( so you can upload ) The Arduino gets around this by a 10uf cap from reset to ground... I can now use the USB to serially connect to the PC without issue... I soldered a jumper on Gnd and Reset and I can place a cap on when I'm working and take it off to upload a new program..

I should imagine the Pic will be in a similar fashion..
 
That's the only thing i didn't try LOL I set the DTR I didn't toggle it in software But I'm thinking just use my serial adapter it works fine with it and no DTR stuff
 
Never heard of that but might get one of those and try that too.
I got into st32's 'blue pill' clone from one of nige's posts, they are an interesting device.
 
This nothing like a st32 blue pill

It's a 20 pin pic with a sam as programmer you only get use the 16f18446

But the sam looks like a flash drive and usb serial I have a bigger one the CDC worked no problems this one doesn't let me use it but it was free
 
Thought this is worth sharing.

I have six open tickets with respect to the new board. With two more to add.
00309614 CNANO Curiosity NANO USB - 16f18446 Board driver installation failures on Win7, Win8.x and Win10 - various errors. I have posted a patch kit to resolve the missing drivers.
00310392 CNANO Curiosity NANO USB - 16f18446 - Config - the unpublished configuration. Work in progress with Microchip Product Development.
00310394 CNANO Curiosity NANO USB - 16f18446 - Initial Firmware - the initial firmware, a bootloader and why do you need to power cycle the board so often... Work in progress with Microchip Product Development but there is no bootloader and they dont yet have the power cycle issue sorted.
00310395 CNANO Curiosity NANO USB - 16f18446 - Documentation - the incorrect URL access from the Virtual Drive. Microchip will revise the referred web page... but, they need help to identify all the documentation needed. Work in progress with Microchip Product Development.
00310396 CNANO Curiosity NANO USB - 16f18446 - Documentation - debuggers, virtual comm port error and lots more of documentation misisng. Work in progress with Microchip Product Development.
00310397 CNANO Curiosity NANO USB - 16f18446 - Firmware ERROR!!!! - corruption of firmware when transferring via the USB/CDC. Work in progress with Microchip Product Development.
To be added - Linux unable to boot with board attached.
To be added - Linux serial device. Under Linux, the /dev/ttyACM0 error.

On Twitter I have called this XpressFrankenBoard. :) It is a mix of both Microchip and ATMEL.

The tickets and the resolutions will be posted here; https://sourceforge.net/p/gcbasic/discussion/demonstrationcode/thread/97d1ec43/?limit=250#7f5f I wont have time to post everywhere.

I am creating a webpage this weekend with all my communications with Microchip, and, I will post to https://sourceforge.net/p/gcbasic/discussion/demonstrationcode/thread/97d1ec43/?limit=250#7f5f the results of my next meeting with Product Development to resolve the issues.

I have posted lots of demos for the board, see GitHub at **broken link removed** I have also posted a lot of documentation and the driver pack.

I will post again once I get the webpage written - enjoy XpressFrankenBoard
 
In what way?, do you mean the development board?, rather than the PIC?.

The development boards use an ATMEL processor for the USB and programming interface - a far more powerful device than the lowly PIC it's programming :D

It's good tech, well worth the price.:D
 
Well I figured whats happening here the nEDBG acts as a Virtual COM Port is holding the 16f18446 in reset.
waiting on I guess the dtr to toggle
 
waiting on I guess the dtr to toggle
You don't want it to toggle... You only want it to toggle when updating, when used as CDC you put a cap on the reset to STOP the toggle..
 
This not a arduino
there no pin hooked to the reset

The sam needs a in stoftware DTR toggle to tell it you want use the Virtual COM Port

What happens is it holding the 16f18446 if you use usb serial adapter it send the right data out the pin
but if you open the com port the Virtual COM Port is using it stops the 16f18446 dead
Hang up and the usb serial adapter start working agin
 
I put a cap on mclr that stopped the serial ttyACM0 from working there is no DTR from samd21

Screenshot from 2018-07-07 12-10-33.png
 
be80be

Can I confirm that you where you put the cap? mclr to 0v?

This is the context that Microchip told me last Friday that they were not going to document the CDC serial in one message, then, on a conf call they told me they nearly had the debugger operational.

I have spotted the restart of the terminal reset the ports, or, changing the baud rate... this is not the norm for a Microchip product (see Xpress Board 16f18855) and I have told them the new norm is a bad norm.
 
I've tried it both ways it stops the 16f18446 remove the cap and it works with a usb adapter i have
But nothing with the CDC serial But I did find something elase the VCC dosen't have 3.3 volts on it there is nothing.
 
Ive tried it both ways it stops the 16f18446 remove the cap and it works with a usb adapter i have

Being dim here. Both ways? and, both ways stop the 16f188446?

''it works with a usb adapter i have ' means ... if you use PPS to set the 16f18446 then you can use an external usb adapter ok? At the moment this does seems the only stable method to serially communicate.


But nothing with the CDC serial .
You mean... you have no comms? What OS and terminal. I will raise with product support on Monday.

..found something else the VCC dosen't have 3.3 volts on it there is.
Can you check this. I have three boards and I have just checked. All are ok. I have one board on test for the i2c bug and that is providing 3.3v pullup voltage so I am sure this is ok. The vvc I am referring to is 4th pin on right hand side in section 1.2 of the **broken link removed**.
 
Let start over here LOL
If you check the com ports shows up if you try to open a terminal it stop's the 16f18446 from work you can no longer see data showing up on the TX pin.

I tried a cap from mclr to ground and to vdd. Both stop the 16f18446 from sending any data.
Then I checked the VCC pin it has no voltage.

So now I'm looking to see why I have not used the VCC pin It should read 3.3 volts
So I know I didn't kill the regulator or something. I have not used the pin I just tested it. there is nothing on it.
I had no problem with the 16f18855 board I have.
 
If you check the com ports shows up if you try to open a terminal it stop's the 16f18446 from work you can no longer see data showing up on the TX pin. Checking. The 'com ports' is the USB/CDC Virtual Com Port (VCP) ? The experience is reported to Microchip as - if you able to get a Terminal operations when using the VCP and you reprogram then the (host) terminal software either stops communicating or the (host) terminal software displays garbage. Are you saying the 16f18466 TX pin as defined by the PPS instruction on the Xpress board no longer shows data transmission, or, are you saying the ATMEL microprocessor no longer shows data transmission?

I tried a cap from mclr to ground and to vdd. Both stop the 16f18446 from sending any data. OK
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top