I did some more tests and seemingly the RAM program fails if I
overwrite certain addresses. My theory is that the ROM bootloader
requires these and thus fails if I overwrite them. But it's a pretty
weak theory, because I feel it fails for too many RAM addresses. Hmmm...
Have you seen section 3.8 (p58) in the bootloader user manual (UM0560)?
"Note: To execute any of the commands (get, read, erase, write, speed,
and go), the bootloader uses part of the RAM for its own variables and
RAM erase/write routines. Therefore, it is forbidden to run write
commands (with the exception of write commands that are used for
downloading erase/write routines) with destination addresses in the
following RAM locations:
• STM8AF and STM8S Series devices: 0x00 0000 to 0x00 01FF
• STM8L and STM8AL Series devices: 0x00 0000 to 0x00 01FF"
Also, further up the same page:
"Bootloader variables occupy the RAM from address 0x00 0000 up to
address 0x00 009F."
It appears the ROM bootloader reserves the entirety of the first 512
bytes of RAM. Given that the erase/write routines can occupy between
0x00A0 and 0x01FF (that is the extent of the largest s-rec file, the
128KB routines), that corresponds with the statement that the ROM
bootloader code uses the first 160 bytes of RAM as working memory.
So, if you don't want to disturb or conflict with the bootloader
operations, you should probably avoid that entire initial 512 bytes for
static/global variables. I guess you could use the '__at' syntax to
assign specific addresses for any variables.
In a similar context another interesting finding: I tried to jump back
from the RAM routine to the ROM bootloader after a few seconds using
"return;". However that failed. Either I made a mistake or I would
need to know the address in ROM to jump back to :-(
It does seem from the erase/write disassembly that only a "ret" is
needed. But perhaps the bootloader ROM code is expecting some value to
be returned in A/X/Y registers? Although, from a brief scan of the e/w
disassembly, it doesn't look like that. Maybe some global variable is
used - the code certainly reads and writes several locations in the
0x80-0x90 area.
Regards,
Basil Hussain
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
