CDC ACM USBD Binary Mode

RE: CDC ACM USBD Binary Mode

Susheel Nuguru — Mon, 30 Jan 2023 18:55:42 GMT

Sorry for late reply, I did not see that you tested with 7th bit set high when you brute force it in the array. Then I am confused, isn't it the snprintf that is doing the escaping? Can you please check the uartTxBuffer after snprintf?

I am asking to do this even though you think that it is not necessary, because I do not see anything in the usbd code that uses any other external libraries other than memset. And I am confident with the memset behavior but not very confident on how the formatting in snprintf.

RE: CDC ACM USBD Binary Mode

DDGGOO — Wed, 25 Jan 2023 16:53:07 GMT

Please see code snippet above... that combination is in there.

Or are you asking something else?

RE: CDC ACM USBD Binary Mode

Susheel Nuguru — Tue, 24 Jan 2023 09:09:12 GMT

There is nothiing in the USB drivers that I can see which differentiates the data between ASCII and non-ASCII. Could it be the snprintf that is doing this? Can you please do a quick test to manually write the buffer with characters with bit 7 set to high and not use snprintf?

RE: CDC ACM USBD Binary Mode

DDGGOO — Mon, 23 Jan 2023 14:36:55 GMT

Thank you for your response, and good that you are able to reproduce this.

Outstanding / unanswered questions from my previous post here:

It appears that something in the stack is trying to figure out if this is ASCII or not... is this somehow expected behavior?

If we send pure binary via this API, are there any likelihood that this would be escaped?

Perhaps you could pose these questions to the USB driver experts and let us know the answers?

RE: CDC ACM USBD Binary Mode

Susheel Nuguru — Mon, 23 Jan 2023 12:45:23 GMT

Hi,

Sorry for late reply, I am able to reproduce what you tested. It could be a side affect of the use of macros to copy the buffer data into driver storage but I can see the same thing that you see.

Have you have a workaround in mind? If not, I can try to contact the usb driver experts to shed some light on how to have a workaround for this.

RE: CDC ACM USBD Binary Mode

DDGGOO — Wed, 18 Jan 2023 18:10:54 GMT

Hello Susheel,

Thank you in advance for your attention.

Apologies for the delay in responding, have been running various experiments to get additional information on this.
Same ASCII 'escaping' behavior is observed with either nRF5_SDK_17.0.2 or nRF5_SDK_17.1.0.

Here is a code fragment which works perfectly:

// Generic 7 bit ASCII:
snprintf(usbTxBuf, sizeof(usbTxBuf),
         "HDT, %05d\r\n", ourTxCount);
// Invoke transport:
nrfRetVal = app_usbd_cdc_acm_write(&_actAppCdcAcm,   // Instance
                                   usbTxBuf,         // Tx buffer
                                   ourTxCount);      // Number of bytes to Tx

This generates "escaping":

// UTF-8 / ISO 8859 / mixed bit 7 set / clear transmission:
snprintf(usbTxBuf, sizeof(usbTxBuf),
         "HDT, 'À' 'Ä' 'Ö' 'ä' 'ö': %05d\r\n", ourTxCount);
// Invoke transport:
nrfRetVal = app_usbd_cdc_acm_write(&_actAppCdcAcm,   // Instance
                                   usbTxBuf,         // Tx buffer
                                   ourTxCount);      // Number of bytes to Tx

Always nominal return values from app_usbd_cdc_acm_write().

We have confirmed this with binary dumps on the host... this 'escaping' is happening in the Nordic USB stack.

After further experimentation, any character with bit 7 set high is escaped with:

      0xC3 (original char & 0xBF), so "Ä", 0xC4, becomes: 0xC3 0x84

However, sending a pure binary such as:

// Brute force fill in buffer:
      usbTxBuf[0] = 0x01;
      usbTxBuf[1] = 0x02;
      usbTxBuf[2] = 0x03;
      usbTxBuf[3] = 0x81;
      usbTxBuf[4] = 0x82;
      usbTxBuf[5] = 0x83;
      usbTxBuf[6] = 0x84;
      usbTxBuf[7] = 0x84;
      usbTxBuf[8] = 0x00;
      usbTxBuf[9] = 0x0D;
// Invoke transport:
nrfRetVal = app_usbd_cdc_acm_write(&_actAppCdcAcm,   // Instance
                                   usbTxBuf,         // Tx buffer
                                   10);      // Number of bytes to Tx

results in correct, unescaped transmission from Nordic system and correct reception on the USB host.

Even mixed transmission such as:

// Brute force fill in buffer:
      usbTxBuf[0] = 'A';
      usbTxBuf[1] = 'B';
      usbTxBuf[2] = 0x02;
      usbTxBuf[3] = 0x03;
      usbTxBuf[4] = 0x82;
      usbTxBuf[5] = 0x83;
      usbTxBuf[6] = 0xC3;
      usbTxBuf[7] = 0xC3;
      usbTxBuf[8] = 0x00;
      usbTxBuf[9] = 0x0D;
// Invoke transport:
nrfRetVal = app_usbd_cdc_acm_write(&_actAppCdcAcm,   // Instance
                                   usbTxBuf,         // Tx buffer
                                   10);      // Number of bytes to Tx

results in unescaped transmission and correct reception on the USB host.

It appears that something in the stack is trying to figure out if this is ASCII or not... is this somehow expected behavior?

If we send pure binary via this API, are there any likelihood that this would be escaped?

Regards, David

RE: CDC ACM USBD Binary Mode

Susheel Nuguru — Tue, 17 Jan 2023 12:02:20 GMT

Can you please upload some code snippets on how you are doing the 8 bit transfers instead of 7-bit? I can try to replicate it at my end to be able to debug. Which SDK version are you using?