USBD EPIN AMOUNT and MAXCNT values different

[ryan_g]

Hi,

I'm working on treating the nrf as a CDC ACM device and in order to test it I've been using a script to send input to the chip through echo commands to the /dev/ttyACM.

I find that if I don't set a delay on the commands, it'll run through several lines of commands and then the EPDATA event stops firing and the system hangs until it's reset. When the system is hanging I look at the registers to see if anything is abnormal. All of the events have been cleared and handled,  all of the endpoints are enabled, but the EPIN AMOUNT and MAXCNT are different for my bulkIN endpoint. If I step through the code, it works just fine and the registers match so it seems to be a matter of speed.

I checked to see if there's any errata that might be causing this but I don't see anything that would pertain to this issue.

I also looked at the SDK to see if there's any example or place where checking for the two registers to be different could occur, but there's no use of the 'nrf_usbd_ep_amount_get' method in the SDK15 that I could find.

Here's a 2 pictures of my EPIN[2] registers.

In the first picture the MAXCNT register is greater than the amount transferred. In the second picture, the MAXCNT is less than the amount transferred.

Is there something that I'm missing that would cause this behavior?

[Håkon Alseth]

Hi,

 

Q1: Which revision of the nRF52840 are you using? Note that workarounds for older engineering revisions have been removed from SDK v15, and we recommend using the latest production release of the silicon for development.

 

Q2: If you are using the latest revision (engineering C or Rev 1), we have an issue with our current SDK, where the erratas is not properly applied.

Do you have this workaround in your code-base? https://devzone.nordicsemi.com/f/nordic-q-a/34605/usb-not-enumerating-after-reset/133051#133051

 

Kind regards,

Håkon

[ryan_g]

Hi Hakon I'm using revision C. I should have specified that I am not using the SDK for my testing.

I do not have that workaround in my code as I'm not using the errata calls (nor the nordic usb stack although the general structure is mimicked). I do have necessary workarounds applied in my code such as Errata 166 and 187.

I forgot to mention that is issue only comes up on inputs that are coming in quickly via a script. Right now I have to have a 1ms delay between each input to have it working consistently, any faster and the OUT endpoint will not fire EPDATA event anymore.

[Håkon Alseth]

Hi

 

Are you not using any libraries or drivers from the SDK at all?

Have you tried replicating this with the usbd_cdc example in the SDK, with the former mentioned fix present, to see if it behaves similar?

 

Kind regards,

Håkon

[ryan_g]

Hi,

I'm not using any of the libraries or drivers from the SDK in my project as it had to be custom made for the system I'm working on. I tried to replicate the issue with the usbd_cdc example and I'll get a message 'Logs Dropped (1)' which seems like it's losing some input values if it's taking in inputs too fast.

I don't get the same hang that I do in my implementation so I guess I can snoop around what causes that error and how it's handled.

I would have assumed that there would have been locks in place to allow the input buffer to fully be consumed before the next input though.

Thank you.

[Håkon Alseth]

Hi,

 

"Logs Dropped (x)" means that the logger interface is generating too much logging compared to what it can send out (thus flushes x messages), it does not mean that the USB data will be dropped.

Did you check the data pattern to see if any USB data was dropped?

 

Kind regards,

Håkon

[ryan_g]

By data pattern I'm assuming you're talking about the output to the console. It looks like data is being dropped. It'll print out the first few inputs or so and then it will get stuck with this set of messages

<info> app: Bytes waiting: 3
Logs dropped (3)
<info> app: RX: size: 1 char: 7
Logs dropped (1)
<info> app: RX: size: 1 char: 0
Logs dropped (4)
<info> app: RX: size: 1 char: 8
Logs dropped (2)
<info> app: RX: size: 1 char: 

When I stop the input script, it doesn't end up displaying the rest of the expected input that was sent over.

[Håkon Alseth]

Hi,

 

I do not think you should rely on the nrf_log interface to print out every byte, as nrf_log with UART as the backend is slower than the USB.

Instead, do something like this pseudo code and peek at the variables while in debug mode:

// You may need extra logic to handle the initial state of this variable
static uint8_t last_byte;

static uint32_t num_of_failures;
static uint32_t num_of_success;
// Assume receiving iterative data
if (received_usb_data[0] != (last_byte + 1))
{
  num_of_failure++;
}
else
{
  num_of_success++;
}
last_byte = received_usb_data[0];

 

Best regards,

Håkon