Wow my hello world 16f18446 got 21 downloads

[be80be]

The pins are right if you open a terminal using the CDC it stops the 16f18446 from sending data hows that hard to understand

If I don't open terminal using the CDC I can read the pins using a serial adapter.

Something is wrong with the sam21 CDC it's
holding the 16f18446 from transmitting to it some how

 

[Evan VENN]

I am trying to get this understood/documented. As I do have a session with Product Development tomorrow, and, if this is proof then I want to communicate this to them.

The pins are right if you open a terminal using the CDC it stops the 16f18446 from sending data hows that hard to understand.
The pins are right? The port on the 16f18466? but, I am confused. The pins are right then you open a terminal these ports on the 16f18466 change state? But, the overall impact is that 16f18466 that was sending data from the TX pin via the ATMEL part stops sending data (as sampled at the TX pin on the 16f18466 using what?) and the terminal shows no data.


What is the sam21 CDC? Is this an external USB/CDC adapter that is being used to sample the TX pin on the 16f18466?

Can you confirm Operating System and Terminal Software please?

 

[be80be]

If you don't no what the sam 21 is there not much need in telling you.
The Sam 21 is the programmer chip on broad that let you use the USB to the CNANO

 

[Evan VENN]

I am sorry for asking. There is value in telling me as I am collating these issues for my discussion with Microchip product support on Monday.

I am certainly not wasting our time. I am not seeing the same as you but similar. I have been given three boards last week and all three have VCC as 3.3v.

Summary on the comms issue for you, as I understand. The 16f18466 is not sending data from the TX pin via the ATMEL part stops sending data and the terminal shows no data.
Summary on the comms issue for me. Windows 7 and Terminal.exe. The 16f18466 is sending data from the TX pin via the ATMEL part intially. After programming the ATMEL part stops sending data and the terminal shows no data. Changing the baud rate in Terminal.exe and the reverting to the desired baud rate does restore end to end communications.

 

[be80be]

My only problem is the SAMD21 and the on board CDC serial that doesn't work Like I said if I open putty are any kind of Terminal Software it really don't matter
the same thing happens

 

[Evan VENN]

That is interesting. I did not share. I get different results from Putty as compared to Terminal.exe. With Putty, under Windows, I get garbage on the firmware reload and I cannot recover communications.

The video is great. I will share the URL.

Microchip have told me on Friday the following on this regarding my ticket #00310396. 'The use and documentation of the Virtual Comm Port'

The response. Which I have rejected. (Microchip response is in BOLD). I would point out the response has little or nothing to do with 'use and documentation of the Virtual Comm Port' but I think they are tell me that VCP is not for use and when it is... it is for debugging only. I will confirm my thoughts.

#00310396. 'The use and documentation of the Virtual Comm Port'​

The debugging will come at a later stage because it is not ready.
Therefore, all documentation is only mentioning programming support and not anything about debugging (the PCB silkscreen says nEDBG which is the name of the on-board programmer and the interpretation that this name would also mean debugging support is not true at this moment).

As I previously said, we don't provide the source code of the on-board programmer (nEDBG).

My rejection message:

Thank you. But, we need information with respect the Virtual Communication Port - how to use etc.

The Virtual Communication Port (VCP) is required to be documented. As the user can connect the board to a terminal but, a big but, the VCP has some odd characteristics in terms of the tri-state nature of the ATMEL interface. This is an idiosyncrosy of the EDBG '"Note that the UART pins of the EDBG are tri-stated when no terminal program is connected to the Virtual COM Port on the computer. This mechanism relies on the terminal program sending a DTR signal." frokm (Atmel-42096-Microcontrollers-Embedded-Debugger_User-Guide.pdf)

So, when I connected a terminal on Windows I get garbage, this is resolved by changing the port, or, changing the USART speed. And, on Linux my users have NO communications.​

I will get back tomorrow with more information after my meeting with them.

 

[Mike - K8LH]

Burt, can I see your 16F18446 Serial test program, please?

 

[be80be]

Not much to it
If I don't open the com port that shows for the samd21 cdc it will work
open the samd21 cdc it stops dead

Seeing the DTR is in software of the samd21 but setting it in realterm
did help I tried that too.

 

[Mike - K8LH]

Are the Rx and Tx pin assignments in your program correct? The schematic suggests RB6 should be the Rx input and RB4 should be the Tx output.

 

[Evan VENN]

I can sort of reproduce the issue.

'Module: EUSART1
RB4PPS = 0x000F 'TX1 > RB4

With portb.6 as an output I am toggling portb.6 every 100ms. This is happy and the signal is good.
With terminal connected and in the context that you have to raise DTR to get any comms transmission, which works when I raise DTR the comms start on the terminal and portb.6 floats high with comms continuing, lower DTR toggling portb.6 every 100ms resumes and the signal is good.

This has to be something obvious as the root cause.

 

[Evan VENN]

ASM code for my demo - this has the issue where portb.6 floats when you raise DTR on the terminal connected to the VPC.

 

[be80be]

Sorry but

Nothing is showing
Think I posted wrong file I had tried both ways rx to rx and rx to tx just in case but i get nothing
use a off board adapter it works fine im just use it without the on board serial

 

[be80be]

Mike - K8LH this is what i have and I'm using RB4 as TX
The picture shows the output of the nEDBG on ttyACM0 it's all 00
I have a Usb to serial on ttyUSB using the same pins it output is on the right
But the CDC nEDBG has someting wrong in setup

Windows 10 I can get the same output using realterm

 

[Evan VENN]

You do seem to be hitting the same bug as reported #00310396 CNANO Curiosity NANO USB - 16f18446 - Documentation - debuggers, virtual comm port error and lots more of documentation missing. This is Work in progress with Microchip Product Development.

This is a wide ranging bug report but essentially the USB/CDC VCP do not work as expected and has nasty side effects when used. I posted previously that Microchip essentially told me that the USB/CDC VCP is for the debugger, the debugger is not ready and they wont share much.

I have can reproduce your issue - but, as with all the bugs in this board we are pretty well stuck until Product Development come clean with the status. When I reproduced your bug the output port is impacted by the use of the VCP. I have given the ASM and the HEX to Microchip today.

This may provide some insights into what is happening: "Note that the UART pins of the EDBG are tri-stated when no terminal program is connected to the Virtual COM Port on the computer. This mechanism relies on the terminal program sending a DTR signal." See (**broken link removed**) but why does raising the DTR cause the output to go tri-state..... dunno.

 

[be80be]

The link doesn't work https://ww1.microchip.com/downloads...ocontrollers-Embedded-Debugger_User-Guide.pdf
That one works

 

[Evan VENN]

News: Support Case 00310397: CNANO Curiosity NANO USB - 16f18446 - Firmware ERROR!!!!

This is where you transfer a program and the program gets corrupted!

I have been provided a NEW firmware image for the nEDBG. It is intended that the fix should fix the flash programming issue .

I will test this evening when I get time.

 

[Evan VENN]

I am thinking.... the Case 00310397: CNANO Curiosity NANO USB - 16f18446 - Firmware ERROR may be your issue be80be. I discovered last week that the file transfer via the USB/CDC Virtual drive was corrupting the hex file. That failure was during the testing of one of our extensive I2C test programs. However, when I test later and then I will re-test this comms issue. May be it is the root cause.

 

[be80be]

I would like to see a link google finds nothing LOL

 

[Evan VENN]

You will not find until Microchip resolve.

If you think I am bluffing - I am not. I post to Great Cow BASIC - I am one of the main developers. My relationship with Microchip is as an ISV.

 

[be80be]

No I don't think your doing anything but Id like to see where this updated firmware and how to update it cause there is little about the CNANO 16f18446 on the net
Microchips site has nothing and the above link you posted had nothing new I have had this thing for months
I even posted how to get one maybe year ago on this site