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.
You have had the board for months? That is odd. I an unaware of the product shipping before July 18. I thought the board was announced this March but my guy may have missed it until then.
It took over three months to arrive - be nice to think they had been curing the bugs during that time
Am I been a little simplistic here?, but the 16F18877 works fine, why didn't they use the same interface as that? - it's the same series chip, so presumably programmes identically?.
Exactly my thoughts. Search on Twitter for XpressFrankenBoard.
They have shared that the debugger is strategic direction for this type of part. And, you can safely assume (from my conversations with Product Development) that the debugger is to be included in MPLAB-X. So, this is the new norm... I hope not.
They have received very few bug reports. Support last week were not even aware of the boards existence.
We have open tickets with Microchip regarding corruption of the hex during file transfer from the host to the 16f18466 via the USB. Just be aware.
I have posted many demos for the board - the simple stuff works. A program transferred from the host to the 16f18466 via the USB can fail when the same program programmed via the PK3 works.... So, I cannot say that the board programs it just fine - because it does not.
Mine uses a 16F1454 - strange, I thought it was an Atmel processor? - I wonder where I've seen an Atmel processor then?, not on the 16F18466 as that's only recently arrived.
Well I can't see your board but mine has the 18lf25k50 for programmer and debugger and serial to usb
the 16f18446 has the samd21 for programmer and debugger and serial to usb
But looking at there data sheet they show a 16f1454 being used too
OK. I think the earlier issues are not the same board. However, I did get this today on the subject.
This is for the new board shown in post #71. Looks the same issue.
Serial Communication Progress RB4 is connected to the nEDBG UART RX line, RB6 is connected to the nEDBG UART TX line. Any UART character sent to the nEDBG through RB4 is forwarded to the VCP. Setting the DTR bit in a terminal emulator configured the I/O pins of the nEDBG for transmission. The TX line (connected to RB6) is set as an output in the nEDBG, and the input buffers on the RX line (connected to RB4) is enabled. Virtual COM port application...
Therefore, setting the DTR bit in a terminal emulator configured the I/O pins of the nEDBG for transmission. The TX line (connected to RB6) is set as an output in the nEDBG, and the input buffers on the RX line (connected to RB4) is enable and the TX line (connected to RB6) will be impacted.
Nigel Goodwin you will need the firmware upgrade. I am awaiting the next firmware version - should be today/tomorrow. I have asked if I can share but I have no response - as yet.
Well I got the board to work with onboard serial today
So I guess even that work's right after you figure out what your doing wrong LOL
You have to set DTR in software before you open the terminal program
I found a sample on microchips site that listed coolterm downloaded it and set the dtr and guess what it works LOL
We are doing nothing wrong, the user program works when the new board is programmed with PICKit3 Plus. So, the program is good. This IS a bug in the firmware of the ATMEL USB part. I have a second set of firmware from Product Support and results are looking much bett
Latest from Product Support - Corruption of HEX file
"We would like to resolve the issues you are seeing before we provide the updated nEDBG firmware and instructions to all users of the PIC16F18446-XPRESS board."
and
"Product Development confirmed that they could recreate part of the issue on their end, specifically the nEDBG seems to configure its I/O ports and allows transmission if the BAUD rate is changed while the port is connected in a terminal. This is a bug that they will look into fixing."
So, some progress as the second firmware I have does not corrupt the HEX file. But, nEDBG firmware is not correct with respect to serial transmission.
With respect to firmware I have. There is some confusion of the version of the firmware...seems that version numbering has got messed up.
> "My colleagues at the Business Unit confirmed that they could recreate part of the issue on their end, specifically the nEDBG seems to configure its I/O ports and allows transmission if the BAUD rate is changed while the port is connected in a terminal. This is a bug that they will look into fixing."
I am correct in thinking that the goal is that the terminal will work 'out of the box' in terms of transmission from the board. Tell them NOT to break it!
> "We see that you use two COM ports, 13 and 20, are both of these PIC16F18446 XPRESS boards?
> We also noticed an oddity, at 03:18 you use putty to connect to COM13 with 19200, but the title bar of the terminal window at 03:22 shows COM9 at 115200."
Who is 'we'
13 is CNANO Curiosity NANO USB - 16f18446
20 is an external USB/Serial converter.
> "We also noticed an oddity, at 03:18 you use putty to connect to COM13 with 19200, but the title bar of the terminal window at 03:22 shows COM9 at 115200."
Accepted. This is an oddity of the display of Putty. Ignore the "COM9 at 115200" as should have saved the settings.
> "We have not been able to replicate the issue you show at 1:30[previous video], where you click in the left hand terminal (COM13), and then the right hand terminal (COM20) starts transmitting. Do you have any more details to share about your setup?"
> "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."
The terminal needs to operate without DTR otherwise we are commencing a debug operation. So, no... I am not selecting DTR. I do not plan to - ever.
This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
By continuing to use this site, you are consenting to our use of cookies.
