initialization in bootloader and main

Hi Zhaohong,

Treating them as two separate entities is OK, but I do need to pass information between them (trying to use FEE for this). 

Right now when I do module initialization I call the init function provided in Halcogen.  So for the sci module, I call sciInit() at the start of my bootloader (which runs first) and then at the start of my main application.

How would I reset the module (let's say sci) between the bootloader and main app?  I tried writing a 0 to bit 7 (SWnRST) of the sci module GCR1 register, but this does not seem to have an affect.

Can you explain what you mean by "a software system reset to start the application", and how to do it?

I know I can cause a system reset by writing to systemREG1->SYSECR...but that would reset into the bootloader.  To go from the bootloader to main I do the following (based off of the TI example bootloader)

 

    transferAddress = (uint32_t)PROGRAMFLASH_BEGIN_ADDRESS;
    ((void (*)(void))transferAddress)();

Thanks,

David

David,

This forum thread would you more information about bootloader and application.

e2e.ti.com/.../225447

In general, bootloader and application are two separate CCS projects. In the above forum thread, the bootloader occupies address from 0x0 to 0x7fff. Application starts at 0x8000. The application interrupt vector table is defined at 0x8000. After a reset, CPU will start with the bootloader, bootloader will check if any bootloading is required by checking predetermined Flash locations, or I/O pin states, etc. If no bootloading is needed, CPU will branch to 0x8000 to start application. During the development phase, you can move the application interrupt vector table to address 0x0 to debug the application without bootloader.

Would you please provide details about why you consider software reset on SCI does not work?

Thanks and regards,

Zhaohong

Hi Zhaohong,

I say that the reset I was trying by writing to the GCR1 register isn't working because my main application seems to get stuck in the sciInit function. I am trying to check what the proper way to reset the module (without resetting the system) is.

I have my bootloader as two separate projects, and have the starting addresses and interrupt vectors for both set up OK.


For me it is not as simple as just jumping straight to the main application if a software reset is caused. We use software resets for other reasons where we want the bootloader to run, either to force it to stay there so the main application can be updated, or at least so we can run a checksum on the area of flash the main program resides in to make sure it is valid.

David

David,

In the bootloader, I think that there always a condition that no bootloading is needed. Under this condition, you can do a checksum on flash but you do not need to touch any peripherals.

Would you please provide more detail about where CPU hangs up in sciInit function?

Thanks and regards,

Zhaohong

At the very least I need to initialize the FEE module in both, but I won't initialize any other modules in the bootloader unless the main app checksum fails.  I will post my results once I have them.

 

In the meantime, what I did was change the reset vector for my main app from _c_int00 to #-8.  Then when the bootloader jumped to main, I loaded symbols  only for the main program and then ran it, it gets stuck on the line below, I can't step over the line or tell the program to run

 

 

It looks like some of flash isn't being programmed properly, and our error monitoring didn't catch it.  I am hoping this is the cause of all of my problems, but I will keep in mind what you have said about the modules.

David,

I would suggest to take a look at the the disassembly window to see the actual code in the Flash or RAM. If you just want to debug your main application, I would suggest skip bootloader for the moment.

Thanks and regards,

Zhaohong

It appears some of flash wasn't being programmed correctly because it was crossing the bank boundary. Now that I have resolved that I am not longer having an issue.

Thanks,
David