• 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


Well-Known Member
Thread starter #81
"This is probably stating the obvious, but in both Br@y and CoolTerm you are supposed to press the "light bulbs" in the lower right hand corner to set the DTR signal."
Not so that doesn't work you have to set the com port up in options first then open the port if you try to change it after the com port opens it hang's the port or messes up loading hex's

Then you have a problem with Linux the stty program that is used does not have a DTR command it's done with a work around to let you set dtr stty has none.


Well-Known Member
Thread starter #83
Simple lol
You have to set the options first

Linux doesn't use DTR on com ports if you read the man page DTR is not really for what microchip is doing here in linux you have only a CTS command
To use the dtr you have to write a warper that set's dtr coolterm has the option to do so
Dont agree.

Setting DTR will cause the new board into debug mode. Setting DTR will then change the operating status of the Microchip part in terms of the communication lines between the ATMEL part and the Microchip part.
Without DTR set the terminal should operate as normal.
I have just got off calls with Microchip and these are the correct assumptions.
With respect to programming. Some insights.

The recommended CONFIG setting is LVP = 1 and MCLRE = 1 in the PIC16F18446 on this new board. Note therefore the constrained use of Re3.

I have now, with the latest firmware, programmed the hex through the mass storage drive and verified that the application flash is written correctly.
The board operates as expected when the application is programmed.

I have also completed the following test:
WRITE: 0A000E00 8F3F FE3F 9F3F FF3F FF3F 83
READ: 0A000E00 8F3F FE3F 9F3F FF1F FF3F A3

The hex writes the LVP bit to 0, as the nEDBG does not support high voltage programming and programming process flips the LVP to 1 before programming.​

All this information is missing in the Xpress user guide. This has been logged as bugs and Microchip will update the documentation.


Well-Known Member
Thread starter #86
Whatever you think setting the DTR wrong cause lot's of problems but The serial didn't work till I used coolterm and set it as shown

This tells you you have to set dtr to use the com port of the nEDBG
Screenshot from 2018-07-11 07-54-18.png
I will share more. When you reset the new board, with the original firmware, the ATMEL firmware sets the VPC port correctly for and two bytes are transmitted to a terminal without DTR high, then VPC communications stops. When you reset the new board, with the latest firmware, the ATMEL firmware sets the VPC port correctly for 32 bytes to a terminal without DTR high, then VPC communications stops.

So, something is not correct.


Well-Known Member
Thread starter #88
Here what I don't get from what your saying the only data sheet they printed is wrong.
But this is my finding the stuff in it works as said I use Linux mostly from what I found out they cutout control of the DTR years ago so my ubuntu didn't have a way to set DTR.
But programming and debugging worked fine only the com port that didn't.
Next I gave a try on windows 10 using realterm didn't work there too found coolterm and set the options to match the datasheet and it all works now
debugging progamming and the comport

So what broke there.
It's like it said my problem was I had no program for serial in linux that let's you set the dtr and the one for windows 10 that did wasn't doing so from what i reading most any that's usb to serial don't cause DTR is really not used much for that it was used back when we had serial printers not a comport talking to a uc LOL
Then, wait for the firmware. The current firmware is not safe for production.

I would not be making this up. There are serious issues in the firmware.

I got this today from Product Development. I video'd the serial errors.

At 02:16 you showed that you are able to receive a many bytes at power-up / early initialization of the board.
This is unfortunate and may be related to the initialization state in the nEDBG firmware, a bug has been logged to investigate the boot state and fix the issue.​


Well-Known Member
Thread starter #92
The whole thing not safe you wouldn't use that in production you would buy a 16f18446 and make a PCB install a programmed chip LOL
Did you mean.

The whole thing not safe. You wouldn't use that in production. You would buy a 16f18446, make a PCB and the install the ATMEL programmed chip.

You agree. Good.


Well-Known Member
Thread starter #94
No Id forget the SAMD21 and use a just the 16f18446 and program it with a pickit 3 or 4

Nigel Goodwin

Super Moderator
Most Helpful Member
No Id forget the SAMD21 and use a just the 16f18446 and program it with a pickit 3 or 4
Of course you would, the board under discussion is a simple development board - for any serious project you'd then move to the plain chip - in fact I got plain chips while I was waiting for the board to come :D


Well-Known Member
Thread starter #96
I like the 16f18446 moved on to adc the 12 bit looks fun.

I have 3 of the boards 16f18877 16f18855 and this one 16f18446

I order 3 tubes of chips the 28 pin and 40 pin of 16f18855 the 16f18875I like these newer chips
Last edited:


Well-Known Member
Thread starter #98
I was playing with the adc it's 12 bit why an i getting 1715 when the pot is at 3.3 volts should it not be 4096



Well-Known Member
Thread starter #99
Oh forget the above post lol it was a bad pot LOL i burnt some of them up setting a 317 with them the LM317 had pinout wrong
I just changed the pot
this looks way better
Screenshot from 2018-07-12 00-28-28.png
That's sent out using a 32 bit buffer using hardware Interrupts
Think if I keep playing with xc8 i'll be doing something useful soon LOL

Nigel Goodwin

Super Moderator
Most Helpful Member
Just a little update to this thread, which hopefully might help others.

I've been working on a 16F18446 project for the last few days, using XC8 1.45 - and have been seriously struggling, first I couldn't get the I2C working, there were no signals on the allocated pins - and gave up on it for now. Next was the UART, the TX part was working fine, but not the RX part - after hours of struggling I decided to examine the header file (I was THAT desperate) - to find that the PPS address allocations were wrong in the header file. Editing the header file means the RX side works OK now, the I2C PPS addresses were wrong as well, and I've got signals on the pins now - but nothing 'working' yet, I may have broken some code with my previous changes to make it work.

So if you're using XC8 v1.45 be aware that PPS may not work, and if not check the header file and compare it with the datasheet.

Anyway, I've just downloaded XC8 V2.0 (I hadn't bothered before, because it basically just adds AVR support), but it also adds a correct 16f18446.h header file :D

Latest threads

EE World Online Articles