Debug problem on CDC ACM example

[alexlöddeköpinge]

Hi everyone,

I'm using ses IDE to debug via J-link on nRF52840 DK.

I'm debbuging CDC ACM example (I haven't changed it) but  when I debug:   ret = app_usbd_cdc_acm_write(&m_app_cdc_acm, m_tx_buffer, size) I have that ret is not NRF_SUCCESS,

Why?

BR

[Karl Ylvisaker]

alexlöddeköpinge said:

Maybe you are referring to this error code?

Yes, thank you, this is exactly the error code I am referring to.
To start looking into the error we also need to see which function that returned the NRF_ERROR_BUSY. The error message indicates that the error code was passed to an APP_ERROR_CHECK on line 357 of main.c
Which function returned the error message passed to the APP_ERROR_CHECK at line 357?

Best regards,
Karl

[alexlöddeköpinge]

Karl Ylvisaker said:

Which function returned the error message passed to the APP_ERROR_CHECK at line 357?

ret = app_usbd_cdc_acm_write(&m_app_cdc_acm, m_tx_buffer, size);

I haven't changed anything in the example so I don't understand where the problem is. Is it a bug in the SDK?

[Karl Ylvisaker]

alexlöddeköpinge said:

ret = app_usbd_cdc_acm_write(&m_app_cdc_acm, m_tx_buffer, size);

Thank you for clarifying.
With the returned error code and which function that returned it, we can start looking into what triggered it.
We start with looking at the API Reference documentation for the triggering app_usbd_cdc_acm_write function. We see here that this function is a higher-level function, which will return standard error codes as generated on the lower levels. We therefore look into the source code of the usbd_cdc_acm driver, to figure out why this error was generated - we find this file located at SDK_ROOT\components\libraries\usbd\class\cdc\acm.
We see that it in fact returns the error code of the app_usbd_ep_transfer function.
An exempt from the app_usbd_ep_tranfer_function API documentation reads:

NRFX_ERROR_BUSY

Selected endpoint is pending.

So, it seems the endpoint is pending.
Are you getting this error when you run the completely unmodified example, or have you made any changes ( like calling the write function periodically, like discussed in your other tickets )?
Could you tell me how to provoke this error, so that I may try to replicate it?

alexlöddeköpinge said:

I haven't changed anything in the example so I don't understand where the problem is. Is it a bug in the SDK?

That is of course always a possibility, but it is not the most likely one.

Best regards,
Karl

[alexlöddeköpinge]

Karl Ylvisaker said:

Are you getting this error when you run the completely unmodified example, or have you made any changes ( like calling the write function periodically, like discussed in your other tickets )?

I get this error when I run the completely unmodified example. I downloaded the SDK and then using SES I flashed the nRF52840DK.

I want to clarify that the program works correctly. As I'm new to programming, I tried debugging despite the program working. It is by doing this that I encountered the problem I was telling you in previous messages. I hope my message is clear, sorry but I am using translator and it may not be clear.

Thanks again.

[Karl Ylvisaker]

Hello,

alexlöddeköpinge said:

I get this error when I run the completely unmodified example. I downloaded the SDK and then using SES I flashed the nRF52840DK.

I want to clarify that the program works correctly. As I'm new to programming, I tried debugging despite the program working. It is by doing this that I encountered the problem I was telling you in previous messages. I hope my message is clear, sorry but I am using translator and it may not be clear.

Now I understand, thank you for clarifying this. I am happy to hear that the example is working correctly.
As I mentioned before it is absolutely possible that this particular issue is caused by the debugging itself - since the CPU is halted between debugging steps the communication might fail as a result. This could indeed be what is causing your issue.

Best regards,
Karl