mqx boot

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

mqx boot

663 Views
dingo
Contributor III

I run a simple test application (twr 60N512)  initial with intvect =0x0 , and all was OK , I try to change the Linker parameters Intvect to 0xb800 and also the ROM start to 0xb800, and the application crashes . I work  with IAR 6.1 and MQX 3.7  , in debug mode with Go command the application terminate at address 0xfffffffe in dissasembly window.  Can anyone help me .

0 Kudos
3 Replies

415 Views
dingo
Contributor III

mean time I read more and I reformulate the question. A simple gpio program on TWR 60N512 and MQX3.7  with intvect at 0xb800 and ROM start at the same address (configured in Linker options) run correct in debug mode (Go command) . If I try to run the program without debuger,  the program didn't work, and I think that is normal (after reset the processor run from flash address 0x0000)  but my question is :  how the debuger can make run this program ? The memory window for addresses 0x0000 to 0xb7FF is blank (0xff in each location) .

It is important to get an answe to these ,  because the same procedure can be applied in bootloader applications to start the application code that resides at a different address in flash than 0x0000.

 

thank you

0 Kudos

415 Views
OldNick
Contributor IV

dingo wrote:

 but my question is :  how the debuger can make run this program ? The memory window for addresses 0x0000 to 0xb7FF is blank (0xff in each location) .

It is important to get an answe to these ,  because the same procedure can be applied in bootloader applications to start the application code that resides at a different address in flash than 0x0000.

 

thank you


Hi, Going through a similar process (in thought anyway)

The debugger (if you are using SWD or JTAG or some emulation), can set the Instruction Pointer and other registers directly.  Without a debugger, you can't.

 

A stub application at 0x0000 which sets teh vector table and jumps to your start address would be the basis of a bootloader. 

 

But beware you cannot delete the code you are running from!  So if your bootloader does a flash-erase-all, it had better be running from RAM by then, or you have a dead board and will need a debugger to get it alive again.

 

Plus, if the power goes out between flaash-erase-all and re-programming the bootloader, you have a dead board anyway.:robotsad:

0 Kudos

415 Views
dingo
Contributor III

OldNick thank you, I don't think that what the debugger can make,  the bootloder didn't , so the program counter PC can be loaded in the bootloader with the application start address in this case 0xb800 , I try this (with my experimental bootloder)  but didn't work,  probable the intvect must be moved also to 0xb800 . I don't know if the intvect can be moved ( from 0x0000 to 0xb800 in internal flash) at run time in bootloader.  Also I tried to move the intvect in RAM for an application that previous work OK with intvect at 0x0000, but after I configure #define MQX_ROM_VECTORS 0,  rebuild bsp and make the original project the application didn't work.

0 Kudos