Hi all
I am having problems with application startup. My USB based bootloader needs to start the "real" application if no USB is present. So I got two separate programs in flash residing on different locations. Bootloader starting at 0 (with flash vectors) and the application at say 0x4000, using relocated rambased vectors.
Both applications work fine, if started from within the debugger (PC set to either 0 or 0x4000, then command "go").
USB Bootloder is in Thumb mode, but I issue the BX R0 with R0 set to 4000h from supervisor mode. The application starts, but then ends up in an exception shortly. Any ideas what might be wrong? Does the CPU need some more setup? Or causes the duplicate clock stuff in the startup code some problems?
Funny thing is I checked NXP's app note 10711, which is about an USB bootloader too and they start the application simply that way:
void execute_user_code(void) { void (*user_code_entry)(void); user_code_entry = (void (*)(void))USER_FLASH_START; user_code_entry(); }
The bootloader is in Thumb and User mode I guess. Can that generally be a workiing solution? I tried it that way at first, but failed too.
Many thanks in advance U.B.
Thanks Tamir, but ..
if you read the OP , I stated there that the applications works well, if started directly, thus the remapping should be OK and yes, supervisor mode is set
So the only thing left is that IRQS are left turned on. Will try that and turn them off
btw, does the Keil startup code really work for remapping? I can neither see how the original vector set is being copied to RAM and how the first 64 bytes are being held free from normal program usage only by setting REMAP etc.
Ulrich, the latest keil startup file for the LPC2400 family supports remapping of the vector table. have a look at the files provided by MDK 3.40, for example. either way you can always copy the vectors your self (64 bytes to address 0x40000000), not forgetting to set MEMMAP to 2 and disabling interrupts.
If I manually (by debugger) set PC to 0x4000, the main application runs well, so I think my remapping stuff should be fine ;)
hey all again ..
NO IDEAS ? PLEASE ...
the job seems so simple but my target crashes and crashes.
Double-checked several times without result:
Bootloader leaves its code in supervisor mode, interrupts off, all VIC IRQ disabled jumping to 0x4000 (where target was loaded to properly)
target code is really there and operation starts in the usual way by executing the target startup code INCLUDING copying and remapping of the 64 b vector area.
the SAME target code works fine if started by debugger. what else might be wrong ?
many thanks in advance Uli B.
provide details please: when does it crash, and how.
COOL - I finally got it.
Decided to go the hard way and walk the entire startup (assembler ad my own 'C' stuff) along with the debugger
1) USB Bootcode sets all PINSELS to 0 except for the few needed for USB
2) Target application resets all PINSELS to 0 to start with "a clean CPU" and then adjusts all values as needed. (USB is only used for firmware upgrades, so appliations doesn't need it)
the bad statement is
PINSEL1 = 0; (this would reset some USB/port pins)
replaced it by
PINSEL = 0x14000000; (thus keeping the USB fxns of the pins) and the app runs as expected.
damn crazy !
is that "feature" documented somewhere ?
Forgot: this "effect" does NOT happen if in debugger;)