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

[alexlöddeköpinge]

Yes, I have DEBUG defined in my preprocessor defines.

How can I view the logger output?

Sorry but I'm new at programming with SES

BR

[alexlöddeköpinge]

Karl Ylvisaker said:

If you open a serial terminal, like PuTTY or Termite, and open the port to which the device is connected, then you should see outputs by the device when it is running. It will print some messages as the application initializing, and then again if it encounters some error or receives data through the USB.

Yes, now I see outputs on Termite. The problem is that there is not any error message (I see only info as the application initializing). The program works fine as ret=NRF_SUCCESS 

The only problem is during debugging, when I debug seems that ret is not NRF_SUCCESS.

It's like there's a difference beetween debug and when the program is flashed in the nRF52840.

Thanks

BR

[alexlöddeköpinge]

Karl Ylvisaker said:

Defining DEBUG in the preprocessor defines will make a detailed error message be written to the log, which we may then use to identify the issue the application is encountering.

<error> app: ERROR 17 [NRF_ERROR_BUSY] at C:\Users\blackp\Desktop\DeviceDownlo                                                                                                                                                                                        ad\nRF5SDK1702d674dde\nRF5_SDK_17.0.2_d674dde\examples\peripheral\usbd_cdc_acm\main.c:357              

Maybe you are referring to this error code?

Thanks

[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