This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP432E401Y: LDR causes "illegal mnemonic error"

Part Number: MSP432E401Y
Other Parts Discussed in Thread: UNIFLASH

In order to make the bootloader load 1 of 2 application images available depending on a bit set in a flash segment, I have modified the boot_serial_emac_flash example.

bl_config.h: replaced APP_START_ADDRESS by two new variables plus the position of the selector variable

#define APP_START_ADDRESS1       0x0000A000
#define APP_START_ADDRESS2       0x00100000
#define APP_SELECT               0x00009FFC

On bl_startup_css, I keep importing the header file as before:

.cdecls C, NOLIST, WARN
%{
    #include "bl_config.h"
%}

In order to do the switching, I added the following code after the ProcessorInit line:

;;
;; Initialize the processor.
;;
bl      ProcessorInit

;; NEW CODE STARTS HERE
    
;; Read the value of the memory address and store it in APP_SELECT.
;;
ldr     r5, APP_SELECT
ldr     r6, [r5]
str     r6, APP_SELECT

;;
;; Check if mem_value is 0 or 1, and select the APP_START_ADDRESS accordingly.
;;
cmp     r6, #0
beq     use_app1
cmp     r6, #1
beq     use_app2

;;
;; Check if mem_value is 0 or 1, and select the APP_START_ADDRESS accordingly.
;;
cmp     r6, #0
beq     use_app1
cmp     r6, #1
beq     use_app2

use_app1:
    ldr     r5, APP_START_ADDRESS1
    b       continue
use_app2:
    ldr     r5, APP_START_ADDRESS2
continue:

;; NEW CODE ENDS HERE

;; Call the user-supplied low level hardware initialization function
;; if provided.
;;
.if $$defined(BL_HW_INIT_FN_HOOK)
.ref    BL_HW_INIT_FN_HOOK
bl      BL_HW_INIT_FN_HOOK
.endif

The rest would then be done in the CallApplication function. However, I get a lot of illegal mnemonic errors starting with the first ldr line. Why?

Thank you and regards
Peter

  • Hi Peter,

      I don't think you can do a LDR with a 32-bit immediate.   You should load APP_SELECT to a source register (e.g. R1) using MOVW and MOVT and then use the LDR to load from the source register (e.g. R1) to the destination register (e.g. R5).  

    https://developer.arm.com/documentation/ddi0439/b/Programmers-Model/Instruction-set-summary/Cortex-M4-instructions

    https://users.ece.utexas.edu/~valvano/EE345L/Labs/Fall2011/CortexM_InstructionSet.pdf

    The startup file has the below snippet for reference. 

    movw r0, #(VTABLE_START_ADDRESS & 0xffff)

    movt r0, #(VTABLE_START_ADDRESS >> 16)

  • Hi Charles,

    Based on boot_serial_emac_flash example and your comment about the 32-bit values, I have created a minimal project which for now only calls the essential part of CallApplication with the image selection and other features to be added once the image switch will be working.

    In CallApplication, I have set VTABLE_START_ADDRESS 0x20000000 and APP_START_ADDRESS1 0x00080000. I have compiled the bootloader and the actual application as bin file and I have tested the bin of the application to work fine in case copied to the beginning of the flash.

    Using Uniflash, I have uploaded the images to the device:

    So, for testing purposes, I have 2 copies of the same firmware at 0A000 and at 80000.

    My expectation would be that the bootloader starts and then replaces itself by the application located at 0x00080000. I can debug through the bootloader code until the end, i.e. "bx r0" and it all looks good. However when I would expect the main application to start, I get a JTAG error "CORTEX_M4_0: Can't Run Target CPU: (Error -1268 @ 0x1090001) Device is locked up in Hard Fault or in NMI. Reset the device, and retry the operation. If error persists, confirm configuration, power-cycle the board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.12.0.00150)" and the disassembly view goes to nowehere:

      

    As in order to not to overwrite the bootloader in operation, I had to copy the vector table to 0x20000000, do I need to change anything in the build settingo the application?

    Regards
    Peter

  • Hi Peter,

      Your first screenshot is unviewable. 

      In Uniflash, you can load the bootloader, your firmware1 and firmware2 all at once provided you provide the correct offset so that Uniflash knows where to program the two firmware images. Also the firmware1 must be  linked to 0xA000 during build time and the firmware2 must be built and linked to 0x80000. 

      If you look at the boot_serial_flash_app2 example, the application is allocated to 0x4000 during build time.