ADuCM355 On-Chip Kernel Bootloader Questions

Hello,

After resetting the ADuCM355 with a J-Link debugger (through the external RESET pin) I am encountering unexpected bus fault exceptions:

I believe the faults on memory accesses are occurring because my application does not include a checksum for the On-Chip Kernel Bootloader's user space integrity check. Referring to Figure 7 from the ADuCM355 user boot loader application note (https://www.analog.com/en/app-notes/an-2058.html):

The IAR linker script (https://github.com/analogdevicesinc/aducm355-examples/blob/master/examples/DigitalDie/M355_Bootloader/iar/user-bootloader-sample-application.icf#L144-L159) suggest that the first page of flash memory (2kB, 0x0-0x800) is the only region of user space flash checked for integrity. Also, the comment suggests the checksum is optional.

My questions are:

  1. What region of flash memory is a checksum computed for by the On-Chip Kernel Bootloader?
  2. Is this flash integrity check optional?
  3. Finally, will the On-Chip Kernel Bootloader cause DCode and ICode memory access to fault if the bootloader's integrity check fails?

I am intentionally limiting my discussion to the On-Chip Kernel Bootloader's behavior. A user bootloader is not a concern at this time.

Thank you,

Matt

  • 0
    •  Analog Employees 
    on Oct 19, 2021 8:54 AM

    Hi 

    1. Checksum is computed for the region ( 0x1F7FC to 0X1F780 )

    2. It is not optional. 

    3.  For details, refer to "PROTECTION AND INTEGRITY" section of UG-1262 ADuCM355 hardware reference manual (Pg 190).

  • Thank you for the reply Akila. I still do not  fully understand the On-Chip Kernel Bootloader's operation, so I hope you do not mind if I ask a few more questions. I still do not know enough to solve the bus faults.

    When you say the checksum is computed for 0x1F7FC to 0x1F780, I assume you are referring to the 32-bit signature at the top of flash page 64:

    I compiled an example program with IAR (M355_ECSns_CapaTest) to see what the application will program to flash at that address. To do this, I converted the .elf (named .out by IAR) to a .hex with arm-none-eabi-objcopy and inspected the flash contents in JFlash:

    The example applications DO NOT program a 32-bit signature at address 0x1F7FC. (This can also be verified through the IAR debugger, or through reading flash out of the chip).

    However, I do see that a CHECKSUM region of memory is defined within the .elf at the end of page0:

    This supports my theory that the data in memory between 0x0 and 0x7FC is used to calculate a checksum and the 32-bit checksum is stored at memory address 0x7FC. Further, I suspect the On-Chip Kernel Bootloader is consuming the value at 0x7FC to determine if it is safe to execute user code.

    • Could you confirm/deny my theory? Please let me know if something is wrong or missing.
    • When you say "Checksum is computed for the region ( 0x1F7FC to 0X1F780 )", what region of memory was fed into the checksum algorithm? The space 0x1F7FC-0x1F780 is where the resulting checksum is written (which on example applications is just erased flash or 0xFFFFFFFF).
    • Finally, will the On-Chip Kernel Bootloader cause DCode and ICode memory access to fault if the bootloader's integrity check fails? (I am asking again, because the "Protection and Integrity" section of the reference manual suggests this only occurs if the information space

    I've read "PROTECTION AND INTEGRITY" quite a few times by now Slight smile. I am asking questions on the public forum because I still don't fully understand the On-Chip Kernel Bootloader's behavior.

  • 0
    •  Analog Employees 
    on Oct 21, 2021 10:11 AM in reply to InnaMed_Matt

    Hi,

     It is not the 32-bit signature. This space(0x1F7FC to 0x1F780) is below the user space(0x1F800 to 0x1FFFF).

    This region(0x1F7FC to 0x1F780) is not readable by user.

    Bus errors are also generated if user code attempts to read the protected range of information space.

  • Thank you for the details. However, this does still not explain how the On-Chip Kernel Bootloader decides if the user application is valid.

    Could you please answer the questions related to the on-chip kernel bootloader? Our development cannot proceed without understanding.

    Thank you,

    Matt

  • 0
    •  Analog Employees 
    on Oct 21, 2021 3:44 PM in reply to InnaMed_Matt

    Hi,

    Kindly ensure that 

    1) the reserved regions in the upper most user space are filled with 0XFFFFFFFF.

    2) WRITPROT is 0XFFFFFFFF in order to check if User flash is valid.

    3) By default,  the flash controller generates the signature value. So leave the unused 32 bits paired with the signature word in their erased state (0xFFFFFFFF). Otherwise, spurious ECC errors may occur after device reset (depending on WRPROT configuration) and the device may become unusable.