Hello, I work with an EASY UTAH board with C161U microprocessor and a Flash ST M29F040B 90K1 on target. I'd like to have my program loaded on Flash but executed on RAM. First I work with the blinky example to check the well functionning. When I load the blinky program to flash with the Flash Tool provided by Infineon, I effectively see that the led switch well. For executing the program in RAM, I wrote two different applications, one with the startup code and a copy routine for copying code from flash (segment 1) to RAM. I load this startup application in Flash at segment 0. The second program is the blinky one (without startup code) that I load in Flash at segment 1. When I reset the board, I could observe on oscilloscope a lot of access to flash (CS0) and RAM (CS1). But the led doesn't switch. In the startup code I specify CS1/RAM from 0x80000 with a size of 4K. I am really new to this so I don't know if the program is freeze doing the copying loop from flash to RAM, or if the execution is wrong. Someone have an idea of what is happening? Just to say that I don't want to use the application note 138 because I think this is not the solution to my problem. Effectively I want all my program executed in RAM and not only the critical routines. If someone have an idea or have same problems, I will be very grateful to have some help and to understand what I'm doing wrong. Thanks Regards
Carmen, These lines are configured during reset by holding PORT 0 lines low (SALSEL is configured using lines P0H bits 4 & 3). This is all documented in the '167 Users manual under System Reset. Most development boards have jumpers or switches to control these bits during reset, check the documentation/schematic of yours. You would have to set the address space to 16Mbyte which enables A16-A23. Note that the CAN pins are mapped to A21 & A22. Best Regards Scott
Hi Scott: Because I will implement this function for my project.Do you have any sample code about this function for me reference? my email address: derek@trident.com.tw Thank you. Best regards, Derek
The boot program mentioned belongs to the client who I developed it for so I cannot pass it around:(. Because of the support for multiple processors (each with different flash algorithms) and multiple external flash types, and the limitations on resource use, it is a reasonably complex program. It had about a dozen assembly language modules with several hundred Kbytes source. To do the more traditional approach, follow App 138. It uses memcpy which works just fine. I started out doing it this way (App138) but changed course after a good percentage of the (industrial) customers disrupted the reprogramming in the middle by turning off the power, killing the communications channel or killing the application on the server which downloaded the new program (all this despite strong warnings in the manual, in the release notes and on the screen not to interfere). This left them with a totally dead unit which needed disassembly and special bootstrap software to reprogram the application. The separate boot sector solved this problem but took about 4 weeks to perfect. Best Scott