IAP & ST92F120

[sergio2]

Posted on May 26, 2003 at 14:03

IAP & ST92F120

[sergio2]

Posted on May 17, 2011 at 11:34

I am developing my own source code to make In Application programming for a ST92F120V9Q7 (60 Kb package)

Since, on my application I don't use the internal E3PROM , I would like to be able to use the 4k sector F4/E0 (228000h to 228ffh) to place all the IAP routines, (interrupt, communication, flash write/erase, etc.) to avoid intersegment jumps and the use of RAM for code execution (as in AN1275 application note). Is it possible to write directly in the F4/E0 sector with the ST92F120-EPB? Am I able to make from my BootLoader a JPS to a label located in the sector F4/E0 to run code from this 4K sector?

[johanpauvert2]

Posted on May 17, 2011 at 11:34

These Flash memory blocks are only available for E2 emulation. They should not be accessed directly for code execution or E2/Flash programming operation.

You can define a jps bootloader to jump to any area of your memory. It means Flash programming memory, E3 or an external memory. Because of my previous remark, you should not use this jump to access the Flash memory blocks used for E3. Skywalker

[johan239955_stm1_stmicro]

Posted on May 17, 2011 at 11:34

Sergio,

You should rather use the ST92F150 than the ST92F120 for your development. The ST92F150 is an upward compatible version from the ST92F120 so transition from one part to the other is easy. Check

http://www.stmcu.com/files/mcu/An9pdf

for more information. Also, the ST92F150 has been designed in a smaller technology than the ST92F120 so price should be even better. Take care, Jojo

[sergio2]

Posted on May 17, 2011 at 11:34

Thanks Jojo and SkyWalker

This IAP development is an upgrade of an existing proyect (with ST92F120V9Q7, up to now in production), The migration to 92F150 is scheduled As, I don't want to execute code from RAM, I want to place part of my code in the FLASH0 sector (same flash sector as the reset vector). and the routines for erasing and writting the Flash memory in the E2PROM sector (220000 to 2203FF) The Build of This solution is carried out without errors in the toolchain, but only an Intel HEX file is generated with the total of the code When I want to write this result on the chip using the ST9-EPB with the St-visual Programmer I obtain the following error: FILE : line 922: Address out of range! - STOP loading ! Errors detected while opening F:\11AST9\RT4\object\rt4.hex in FLASH area FILE : line 1: Address out of range! - STOP loading ! Errors detected while opening F:\11AST9\RT4\object\rt4.hex in EEPROM area The ST Visual programmer is waiting two different HEX files, one for the flash sector and another for the EEPROM Sector How should I make to obtain these 2 HEX files from the toolchain?

[johan239955_stm1_stmicro]

Posted on May 17, 2011 at 11:34

Your problem comes from a limitation of STVP9.

There are 2 ways to overcome it. 1. you implement in your boot code a subroutine in charge of copying your routines (the ones for erasing and writting the Flash memory) from ROM to E3. Then you execute this subroutine from E3 2. you modify your hex/s19 file so it works It looks like STVP9 does not support the Extended segment address record from the hex/s19 file. When an extended segment address record is met , STVP9 will stop loading data in his interface and therefore the E3 window will not be updated. You can therefore try this. a. Take your hex file b. extract the E3 information without extended segment address record c. Save this information into a new file d. Load this new file into your E3 tab within STVP9 Method b is ugly but it works. I hope ST will release a new STVP9 without this limitation Take care Sergio, Jojo

[romain2399]

Posted on May 17, 2011 at 11:34

You can use the -Rsection option while generating the hexa file to remove first the E3 part, then all others.

ref_guide1.pdf: -R SECTIONNAME, --remove-section=SECTIONNAME The -R option removes any section named SECTIONNAME from the output file. This option may be given more than once. Using this option inappropriately may make the output file unusable.