I am wanted to write a bootloader. If an application is already programmed, it transfers control to the bootloader with an interrupt call (_trap_0x7F). The bootloader needs several informations form the application (ECU-adress,...). This informations are hold in a struct, which is located at the same adress in the application and the bootloader.
#include <Schnittstelle.H> #pragma NOINIT struct SchnittstellenDefinition volatile far Schnittstelle; #pragma INIT
I declared #pragma NOINIT for disable initialization or clearing the struct. But if i read out the content of the struct in the bootloader, the values are not correct. You said that the contents of the struct were not correct, but you didn't say they were all zeros. It probably means that your problem is not related to the NOINIT pragma. I am assuming that for locating the struct at a specific memory address you used the technique described here: http://www.keil.com/support/docs/586.htm And hopefully you took the necessary precautions when calling bootloader code from the main application, such as saving and restoring registers. It would be very helpful if you could set up a debugger. If that is problematic, you could communicate some debugging info from the microcontroller using some peripherals, like a display or a serial port. Regards, - mike
When the bootloader was called from the application, the bootloader cleared the flash memory sections where the application was programmed in order to programm a new application. So i don't need to save the registers. What must i attend when i want to call the bootloader with an interrupt trap? The interrupt function doesn't restart the bootloader, but calls an function in the bootloader programm. Must i manually set the things which normaly Start167.A66 does? Regards, Mirco
As far as I understand, you already have a main application written as a Keil C project, and you intend to add a firmware update functionality? If that is the case, you need to decide how to sort out switching between the main application and the bootloader. For example, if the application and the bootloader use the same interrupts, you have to figure out how to adjust the interrupt vector table when switching between them. The way I did it was like this: the firmware update code was the first to execute at powerup. I modified its Start167.A66 file so that as soon as it can it checks a flag (a magic number at a certain location) to see whether to continue executing firmware update code or to switch to the main application. Before switching to the main application a checksum of the code was calculated to make sure that a firmware update process was not interrupted buy a power failure. Then the application's interrupt vector table was copied to the appropriate location and a jump to vector 0 was executed. When the main application wants to execute the firmware update code, it writes the magic number to the appropriate location and executes the software reset instruction (SRST). Regards, - mike
Yes! It is an automitive application. The application communicates with an extern tester via a serial port. At powerup first the bootloader executes. When a legal application was already programmed, the bootloader switch to the application. When there is no application, the bootloader runs and communicates with the tester. When the tester sends a special message, the bootloader must start, clear the flash (the old appplication) and then programm the new application sended by the tester. Sharing interrupts is not the problem. It already works. But the boot loader needs some informations from the application. This informations are hold in an struct which is not initilized by the bootloader. The bootloader should started from the application by calling a software interrupt. Because of that, the Start167.A66 of the bootloader is not executed. I must manualy set the things i need (DPP0,...). Could this be the problem? (Maybe this could help you: I set a special value in ram (with MVAR) before calling the bootloader. The bootloader not allocate this adress and didn't clear it. I try to read out the written value in the bootloader. It's value has changed!) Please excused my bad english!
Did you declare the shared struct as near, which is the default memory type in small memory model? In that case the actual memory location where the struct is stored would depend on DPPs. I suggest declaring the struct as huge, in which case the compiler would not rely on DPPs when accessing the struct. - mike