USBD EPIN AMOUNT and MAXCNT values different

RE: USBD EPIN AMOUNT and MAXCNT values different

Håkon Alseth — Fri, 03 Aug 2018 07:42:53 GMT

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

RE: USBD EPIN AMOUNT and MAXCNT values different

ryan_g — Thu, 02 Aug 2018 16:59:34 GMT

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.

RE: USBD EPIN AMOUNT and MAXCNT values different

Håkon Alseth — Thu, 02 Aug 2018 11:24:45 GMT

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

RE: USBD EPIN AMOUNT and MAXCNT values different

ryan_g — Tue, 31 Jul 2018 17:05:01 GMT

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.

RE: USBD EPIN AMOUNT and MAXCNT values different

Håkon Alseth — Tue, 31 Jul 2018 11:57:03 GMT

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

RE: USBD EPIN AMOUNT and MAXCNT values different

ryan_g — Mon, 30 Jul 2018 20:21:22 GMT

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.

RE: USBD EPIN AMOUNT and MAXCNT values different

Håkon Alseth — Mon, 30 Jul 2018 12:19:28 GMT

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