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

[Karl Ylvisaker]

alexlöddeköpinge said:

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 

Great!

What is the error message generated when you are using the debugger?

Please be advised that when you are using the debugger, and halting the program you are actually halting the CPU. This might cause certain timing-critical processes to fail ( such as the SoftDevice BLE communication ), as a result of the debugging.

Best regards,
Karl

[alexlöddeköpinge]

There is not an error messagge. 

int main(void)
{
    ret_code_t ret;
    static const app_usbd_config_t usbd_config = {
        .ev_state_proc = usbd_user_ev_handler
    };

    ret = NRF_LOG_INIT(NULL);
    APP_ERROR_CHECK(ret);

    ret = nrf_drv_clock_init();
    APP_ERROR_CHECK(ret);
    
    nrf_drv_clock_lfclk_request(NULL);

    while(!nrf_drv_clock_lfclk_is_running())
    {
        /* Just waiting */
    }

    ret = app_timer_init();
    APP_ERROR_CHECK(ret);

    init_bsp();
#if NRF_CLI_ENABLED
    init_cli();
#endif

    app_usbd_serial_num_generate();

    ret = app_usbd_init(&usbd_config);
    APP_ERROR_CHECK(ret);
    NRF_LOG_INFO("USBD CDC ACM example started.");

    app_usbd_class_inst_t const * class_cdc_acm = app_usbd_cdc_acm_class_inst_get(&m_app_cdc_acm);
    ret = app_usbd_class_append(class_cdc_acm);
    APP_ERROR_CHECK(ret);

    if (USBD_POWER_DETECTION)
    {
        ret = app_usbd_power_events_enable();
        APP_ERROR_CHECK(ret);
    }
    else
    {
        NRF_LOG_INFO("No USB power detection enabled\r\nStarting USB now");

        app_usbd_enable();
        app_usbd_start();
    }

    while (true)
    {
        while (app_usbd_event_queue_process())
        {
            /* Nothing to do */
        }
        
        if(m_send_flag)
        {
            static int  frame_counter;

            size_t size = sprintf(m_tx_buffer, "Hello USB CDC FA demo: %u\r\n", frame_counter);

            ret = app_usbd_cdc_acm_write(&m_app_cdc_acm, m_tx_buffer, size);
            
            if (ret == NRF_SUCCESS)
            {
                ++frame_counter;
            }
        }
        
#if NRF_CLI_ENABLED
        nrf_cli_process(&m_cli_uart);
#endif

        UNUSED_RETURN_VALUE(NRF_LOG_PROCESS());
        /* Sleep CPU only if there was no interrupt since last loop processing */
        __WFE();
    }
}

/** @} */

At line 67 there is a conditional statement. In the debug phase the condition is not verified and therefore in the debug it would seem that frame_counter is not incremented. However trying the program it results that frame_counter is incremented.

Sorry if I can't explain myself well but I'm not very familiar with English as I am Swedish.

[Karl Ylvisaker]

alexlöddeköpinge said:

At line 67 there is a conditional statement. In the debug phase the condition is not verified and therefore in the debug it would seem that frame_counter is not incremented. However trying the program it results that frame_counter is incremented.

Ah, so it is. I understand. Could you go ahead and add a APP_ERROR_CHECK(ret) right after the line?
This should always be done when an error code is returned, in order to find out whether it was successful or not.
I am not certain why it was not added in the first place in the example, and will create an internal ticket to inquire about this, and ask that it is added in future versions.

If the error is != NRF_SUCCESS then the APP_ERROR_CHECK will print a more detailed error message to the log, before resetting the device ( default error handling ).

Please let me know what the outputted error message says.

alexlöddeköpinge said:

Sorry if I can't explain myself well but I'm not very familiar with English as I am Swedish.

No worries, your English is fine for now and I will do my best to understand what you mean.

Best regards,
Karl

[alexlöddeköpinge]

Karl Ylvisaker said:

Please let me know what the outputted error message says.

The output is:

<error> app: Fatal error
<warning> app: System reset

Also adding the line as you advised me, when I press the button, frame_counter increases by a few units and then the system resets itself automatically. In other words, the program no longer works as it should. I thank you infinitely for your availability and for your precious collaboration. Have a nice day.

BR

[Karl Ylvisaker]

alexlöddeköpinge said:

The output is:

<error> app: Fatal error
<warning> app: System reset

Could you confirm for me which logger backend you are using, and that you have DEBUG defined in your preprocessor defines - like shown in the image I included in my first comment?

alexlöddeköpinge said:

Also adding the line as you advised me, when I press the button, frame_counter increases by a few units and then the system resets itself automatically. In other words, the program no longer works as it should.

Yes, as I mentioned in my previous comment the default error handling done by APP_ERROR_CHECK when it receives an error code != NRF_CONNECT is to reset the device.
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.

alexlöddeköpinge said:

I thank you infinitely for your availability and for your precious collaboration. Have a nice day.

No problem at all, I am happy to help!

Looking forward to resolving this issue together.

Best regards,
Karl

[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.