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?

[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