nrf52840dk Jlink OB USB cdc offsets 1 character

[rfleming]

I have read through similar posts, though none seem to talk directly about the DK and the JLink OB (SAM IC) missing bytes itself.

To start off with, I have created a basic console application on NCS v1.8.0 on my nrf52840dk. Utilising the USB CDC for ease of connection, this removes the need for an external uart interface.

The console app itself seems largely to work because I use the same api calls and configurations on the nrf9160 on a thingy91 board (specifically not on the nrf52840 on the thingy91...for various reasons just go with it ^^). First noticing that my console couldn't handle the data that was being sent, I started echoing the hex of the byte received back over the console and noticed that it was always out by 1 character.

Scoping location:

In the end I used my oscilloscope and scoped the output from the SAM IC to the input to the nrf52840 on P0.06 and TP4. Leaving my probe on TP4 and doing a fresh power up I note the following:

1. No default output occurs from SAM -> 52840
2. Open Com port with baud @ 115200, no hw control IOs set
3. Send 1 byte through 0x30
4. This comes up correctly as 0x30 on the scope
5. send through 0x31, this reads as 0x30 on scope
6. send through 0x32, this comes up as 0x31
7. send through 0x32, this comes up as 0x32
8. send through 0x33, this comes up as 0x32
9. and repeat

It appears as though there might be a bug on my nrf52840dk jlink OB IC. I am unsure how/when this occurred as I believe it used to work just fine and this is a recent acquisition. on my DK, the SAM IC has the following information printed on it:

• PCA10056
• 2.0.1
• 2020.13
• 683824488

I do not believe that I updated my SAM IC's firmware at any point, though if I did, what would be the procedure for reflashing this IC? I do have an external JLink programmer and the special 2x5 1.27mm spring pin cable for programming it if required.

[blablub]

Hello rfleming, I use the same nrf52840dk board as you do. I even have the same rev. 2.0.1 on my table. VCOM was not usable when the issue occurs. (I have also other revisions which show the same issue).

While developing a product, I came across the same weird issues. When typing on the Zephyr shell, I was always lagging a character behind. No one else at my company experienced such issues and we use the boards extensively. This made developing scripts for VCOM unusable.

My findings are:

- I had only a single workstation which caused the problem every time I programmed a new image. Ryzen 5900x with a B550 board. Thinkpads were ok. The workstation was running for months and a cold boot eventually solved the issue.

- Flashing a new FW to the interface MCU resets the problem. But it was persistent until then.

- Never tried a rev. 3.0.0 board, but with rev. 3.0.0 the Atmel chip was replaced with an Nordic one. Maybe it helps.

- When I solder an external FTDI USB to UART adapter to the VCOM pins i have no issues.

[JONATHAN LL]

Hi blablub,

The issue might be a AMD issue, have you tried with an external powered USB hub? 

And also, you can create a new Devzone ticket an link to this and we will try to find a solution with you. 

Regards,
Jonathan

[blablub]

Hi, thanks for your reply. Yes I also tried with an external hub, but still connected to the same AMD USB root controller. I have no other USB controllers on this specific machine. I will open a new Devzone Ticket for that.

[JONATHAN LL]

OK thanks for the update. Go forth with a new ticket and and all your system info, then we can work on a solution there. 
Regards,
Jonathan