Hi Basil,
(as always) thanks a lot for your feedback! Indeed I had missed that
information in the BL manual.
Using your input I checked if returning to bootloader is possible with a
simple return. Here's what I did:
- my test device (STM8S105K6) has 2kB RAM, RAM routine is at 0x500,
i.e. well above bootloader
- I removed everything from the RAM routine except return
- after "GOTO 0x500" (-> call RAM routine) the PC waits a bit, and
then tries to resume communication with the bootloader
Strangely after return to STM8 bootloader the UART baudrate has changed.
Please see the screenshots of Rx/Tx stored at
https://c.1und1.de/@519544109849910202/-RlrrTShRRajv5CbUE1lOA
<https://c.1und1.de/@519544109849910202/-RlrrTShRRajv5CbUE1lOA>
- PC communicates with 19.2kBaud
- before RAM execution, the last STM8 reply (="ACK" for "GOTO 0x500")
is at 19.2kBaud -> ok (see GOTO_0x500.png)
- after return from RAM, the PC sends a "READ" command at 19.2kBaud
-> ok (see READ_CMD_PC.png)
- STM8 reply "ACK" is sent at 133.3kBaud, i.e. 7x higher than before
RAM execution -> NOK (see READ_RPLY_STM8.png)
Additional information:
- neither changing CLK_CKDIVR nor UART2_BRR1/2 prior to the return
has an impact on the reply baudrate
- bytes sent by the RAM routine use 19.2kBaud if CLK_DIV is set to
0x00 -> issue occurs during the jump back to ROM bootloader
Any idea how to proceed? As always thanks a lot in advance!
Georg
Am 28.11.20 um 00:48 schrieb Basil Hussain:
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
_______________________________________________
Sdcc-user mailing list
Sdcc-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/sdcc-user
