This post is older than 2 years and might not be relevant anymore
More Info: Consider searching for newer posts

Migrate CLI over CDC/ACM to project open_bootloader_mbr, but stuck in cli_write

Hi support, 

Firstly, environment as below, 

(1) upon SDK (nRF5_SDK_15.3.0_59ac345)

(2) Nordic Open_Bootloader (example project: Open_bootloader_usb_mbr_pca10056_debug) 

(3) Nordic 52840 DK (PCA10056)

What I am doing is just try to migrate CLI over CDC/ACM to project open_bootloader_mbr, but stuck in cli_write and would not get out as below,  

Can anyone tell me why please? Thanks a lot.

FYI, I have separate the configuration of CLI_CDC/ACM away from that of DFU_CDC/ACM as below,

(1) Setting of  CLI_CDC/ACM

Fullscreen
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

(2) Setting of DFU_CDC/ACM

Fullscreen
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

Regards

J.S.

Parents
  • Hi,

    Can explain/show all the change you have done in the bootloader in order to add CLI support? Out of curiosity I also wonder why you want this in the bootloader?

  • Hi Einar, 

    Thanks for your response. Let me explain you the second question firstly, 

    Re-

    Out of curiosity I also wonder why you want this in the bootloader?

    The product would only talk to an another embedded system via CDC/ACM over USB. So, CLI would be the only way to do maintainance once it is published to customer side. 

    J.S. 

Reply
  • Hi Einar, 

    Thanks for your response. Let me explain you the second question firstly, 

    Re-

    Out of curiosity I also wonder why you want this in the bootloader?

    The product would only talk to an another embedded system via CDC/ACM over USB. So, CLI would be the only way to do maintainance once it is published to customer side. 

    J.S. 

Children
  • Hi Einar, 

    Can explain/show all the change you have done in the bootloader in order to add CLI support?

    Just try to migrate NRF_CLI module to the example project open_bootloader_usb_mbr_pca10056_debug, 

    (1) In SDK_Config.h as below,  mainly to enable NRF_CLI related options and queue etc. Please refer to the files below for details,

    4774.sdk_config.h

    (2) add nrf_cli.c nrf_cli_cdc_acm.c nrf_queue.c nrf_sortlist.c

    to nRF_Libraries folder in the project IDE

    (3) Separate CLI_ACM/CDC settings with DFU_ACM/CDC as I already showed in my first post above. 

    (4) The main NRF_CLI init/start/process as 

    Fullscreen
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    (4) I get the NRF_CLI to envoke the NRF_CLI init/start/process as,

    Fullscreen
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    (5) I didn't get task_manager enabled. 

    Above all is my change. Any thought please? Thanks

    Regards

    J.S. 

  • Hi,

    I do not immediately see anything that sticks out.

    Have you made sure that the bootloader start address is moved sufficiently down so that the bootloader does not overlap with the two last pages (MBR params and Bootloader settings). If so, the code that happens to be placed there would be corrupted. This is a problem since the SES bootloader projects in the SDK are slightly misconfigured, and you will not get a linker error even if the bootloader is up to two pages too big. And in this case, any odd error could happen.

    I still don't understand why you want this in the bootloader though. I understand that you need the USB bootloader for updating firmware via USB. But why do you need CLI in addition? What will it be used for? You write that "CLI would be the only way to do maintainance once it is published to the customer side", but the bootloader should not need any "maintenance"?

  • Hi,

    Thanks for your reply. I have figured out a workaround for this, just commenting out those parts in cli_write. Seems that there is a timing issue there, like when the source code in the cycle waiting for TX_DONE to change tx_rdy, however this while loop blocks the CPU and would not let other procedure continue any more. It is very easy to reproduce such an issue if your developer would like to do this. 

    However I don't know if there is any side effect. Could it get CLI consume much cpu? or something else?please let me know. Thanks.

    Regards

    J.S.

  • Hi,

    It is clear that tx_rdy is not set when waiting for it, for some reason. We have found one bug where APP_USBD_CDC_ACM_USER_EVT_PORT_CLOSE is not properly handled. Is that the case here? If so, the fix could be to put the following line when handling the APP_USBD_CDC_ACM_USER_EVT_PORT_CLOSE event in cdc_acm_user_ev_handler() in nrf_cli_cdc_acm.c:

    Fullscreen
    XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

    If your workaround is to comment out the busy-wait (loop), then this in itself should not increase CPU usage. However, I suspect you might get corrupt logs or a bad state in this case since you are potentially continuing before write operations, etc. are completed.

  • Hi,

    Re-APP_USBD_CDC_ACM_USER_EVT_PORT_CLOSE, I don't think so because at this moment the port physically is still going on firmly. For CLI, it is acceptable to get some packages lost. 

    Actually so far I am not so satisfied with my current software structure because everything is running in a big forever loop and I couldn't predict any CPU consumption or CPU block. I am fond of your task_manager, however I hesitate a bit due to reasons as below, 

    (1) Not sure how mature your task_manager is. Is it still in experiment period?  

    (2) Not enough support document to get me know how to migrate an example to task_manager. I know there is only one example BLE_APP_CLI which is developed upon task_manager. However it is still not enough. For example, how to migrate a bootloader file transfer instance to task_manager?

     Any suggestion? Thanks

    J.S.