Two Projects, Two .mot files, one Micro

[karl]

Posted on February 11, 2010 at 20:15

Two Projects, Two .mot files, one Micro

[Tesla DeLorean]

Posted on May 17, 2011 at 13:40

Couple of thoughts.

The S5 record contains a count of preceding lines, if you join two files either correct it, or remove it. Dump the content of the entire flash space via serial port or JTAG, and validate it. Checksum or CRC the two parts to observed if there is any measurable difference between loading the individual parts, or the monolithic part. Write a parser for your Motorola HEX file that runs on a PC, not difficult, and load it into memory. Verify that it parses correctly, that addresses do no overlap each other. Generate some more automatic linkage to you secondary main() function so you don't have to manually pull if from the linker or map file when ever it changes. Define a jump or pointer at a fixed offset in startup.s, or whatever. ..                 DCD     SVCHandler                ; SVCall Handler                 DCD     DebugMonitor              ; Debug Monitor Handler                 DCD     0                         ; Reserved                 DCD     PendSVC                   ; PendSV Handler                 DCD     SysTickHandler            ; SysTick Handler                 IMPORT  main                   DCD  main          ; +0x40 - Entry Point for C main() function -Clive

[karl]

Posted on May 17, 2011 at 13:40

Thanks Clive.

I have implemented checksums in both the boot and the main app.  they are fine, and work as projects by themselves.

When combining the .mot files, I dump the S7 record from the boot, keep the one from the main app, so the mot looks like

S0:MAIN

S3:MAIN

S3:MAIN

S3:BOOT

S7:MAIN

The combined .mot doesn't have any overlap, and all gaps are filled with FFs.

Like I said, the two projects are completely seperate, so they both contain interrupt vectors (two different sets) and both contain complete initializations for the micro.  Could that be part of the problem?  Do I need to un-initalize the one vector table before initializing a new one?  same with system ticks?

[Tesla DeLorean]

Posted on May 17, 2011 at 13:40

The app note AN2557 has been suggested in other threads.

Things to watch for are the initialization of the stack. The problem with calling main() directly is that ignores the other things the CRT (C Runtime) is doing. Mainly things like copying data from the static segment into RAM, and zeroing out

uninitalized

data. Calling __main might make more sense. Are you using interrupts in the boot loader? Are you initializing clocks, PLLs, etc in the boot loader? I've seen problems where people assume they are running from the HSI clock, and program the PLL. This is a big problem if you are currently running from the PLL. You have to bypass it, or switch to another clock first. The following assembler code could be used to start an image with it's own vector table at the front end. You could put it in the startup.s (or whatever it's called), and call it from C, void RunAppCode(void) RunAppCode    PROC                 EXPORT    RunAppCode                 LDR        R0, =0x801B800 ; Boot Vector SP/PC                 LDR        SP,[R0, #0]                 LDR        R0,[R0, #4]                 BX        R0                 ENDP -Clive

[karl]

Posted on May 17, 2011 at 13:40Thanks again for the suggestions, Clive, I checked the app note, used it, and it worked fine.  put the code in my solution, still failed.

I'm almost embarassed to admit what the issue was....  __disable_interrupt(); was not being called before the jump...

grumble...