• State Verified Answer
  • Replies 9 replies
  • Subscribers 75 subscribers
  • Views 1294 views
  • Users 0 members are here
Attachments (2) Download All
Nordic Case Info
  • Case ID: 321086
Options

The upgrade HASH verification fails because the bootloader does not connect to the j-link RTT Viewer

stars

Hi,

For development using SDK17.1 and keil,Follow the examples in this document for development: Getting started with Nordic's Secure DFU bootloader, a step by step guide - Software Development Kit - nRF5 SDK guides - Nordic DevZone (nordicsemi.com)

DFU (DFU-UART) is required. Due to project requirements, UART in bootloader is changed to IIC for DFU upgrade. A problem is that only the j-link RTT Viewer can successfully verify the HASH value.log Compare the following screenshot:

The current test outputs log information from the UART. j-link RTT Viewer selects Connection or no connection (If the chip is not connected, the HASH verification fails)

From UART to IIC, the following changes have been made:

Have been looking for a long time the cause of the problem, 52811_DFU.zip is the original program used for development.
Please take a look at the cause of this problem. Thank you very much!

52811_DFU.zip

Best regards

Stars

  • 0 in reply to stars

    Hi Stars,

    It seems that the issue could be related to the voltage supply in your case. Have you measured your 1.8V supply under load to ensure that it does not drop below the min. supply voltage (1.7V) when the CPU and EEPROM are running? 

    stars said:
    Is it possible to reduce the capacitance of the reference circuit so that this reduction in charge and discharge time can help us solve the problem? Or can you recommend how we can design to meet the normal operation of 1.8V VCC?

    I don't think you are facing the same problem as the other user. The chip is characterizied and verified with the component values used in the reference circuit.

    Does your design include the optional DCDC inductors? In that case, you could try enabling the DCDC regulator in your bootloader to reduce the peak currents.

    Best regards,

    Vidar

    Edit: Another troubleshooting step could be to replace the calls to NVIC_SystemReset() in the bootloader with while(1){}. Then, attach a debugger to your board after the bootloader gets stuck in the loop. This may help you determine the source of the reset. Maybe it's caused by an error in the IIC communication.

  • 0 in reply to Vidar Berg

    Hi Vidar，

    1.8V comes from a DC regulated power supply:

    However, in the test, it was normal when the VCC was 2V. Doesn't this reduce the capacitor charge.

    We don't have DCDC inductors:

    • Another troubleshooting step could be to replace the calls to NVIC_SystemReset() in the bootloader with while(1){}. Then, attach a debugger to your board after the bootloader gets stuck in the loop. This may help you determine the source of the reset. Maybe it's caused by an error in the IIC communication.

    That's a suggestion we'll put to the test.

    Best regards

    Stars

  • 0 in reply to stars

    Hi Stars,

    I don't think your bench supply should have any problems handling this load, but it might be good to measure the supply voltage using an oscilloscope to confirm that the voltage remains stable and accurate throughout the DFU process. Also, maybe double check if you are meeting the min. voltage requirement for your EEPROM.

    stars said:
    That's a suggestion we'll put to the test.

    Sounds good. Thanks.

    Best regards,

    Vidar

  • 0 in reply to Vidar Berg

    Hi Vidar，

    Thank you very much for your reply. Due to the tight schedule of the project, I felt that the upgrade speed was sacrificed, so I used the normal upgrade method of 100K.

    This ticket can be closed

    Best regards,

    Vidar

Related
Terms of service