-deleted-

Important changes to forums and questions

All forums and questions are now archived. To start a new conversation or read the latest updates go to forums.mbed.com.

9 years, 8 months ago.

Why NMI Handler at bytes 8-9-10-11?

I would like to understand the purpose of the following code and why it is needed?

bootloader.cpp at line 52

                //NMI Handler is at bytes 8-9-10-11, we overwrite this to point to bootloader function
                if (count == 0) {
                    buffer[8] = 0x01;
                    buffer[9] = 0x00;
                    buffer[10] = 0x01;
                    buffer[11] = 0x00;
                }

Question relating to:

Last updated: 06 Dec 2016
Example of a Serial bootloader for the K64F platform bootloader, FreescaleIAP, K64F

Would I be correct that the above code is for the non-maskable interrupt (INTNMI) on the K64F which is the SW3 button. The bootloader overwrites the interrupt vector location with the address of the boot loader. This means that if you press button 3 when any user mbed program is running, it will enter the bootloader function.

posted by -deleted- 05 Apr 2015

1 Answer

Erik -
9 years, 8 months ago.

You would be correct. It modifies the user program to always make the NMI point to the bootloader function.

And why those bytes? Because ARM decided that the NMI handler always recides in that location, making it easier for us.

Accepted Answer

Thank you. I don't understand what 0x01 and 0x00 is referencing or pointing to?

I thought it would be: attribute((section(".ARM.at_0x10000"))) void bootloader(void)

If that is true then how does 0x01 make this possible? If I use a define called ARM_LRA_BOOTLOADER for attribute((section(ARM_LRA_BOOTLOADER))) void bootloader(void) , then how would I change buffer[8] = 0x01 and so on?

posted by -deleted- 05 Apr 2015

Ah good point that I didn't check when looking at your pull request.

First of all, in indeed refers to INTNMI of SW3. Second, the actual function location is at 0x10001 (you can find that out by printing the pointer to that function). Or to write it as 4-bytes: 0x 00 01 00 01. So thats the address it points to, and thats why it has those values. If you change it, take care of the endianness. So byte 8 probably will never change, byte 11 will always be 0 with the memory size available here, so byte 9 and 10 need to be modified. (If you only do multiples of the current size also byte 9 does not need to be changed).

posted by Erik - 05 Apr 2015