Hi,
thanks a lot! Basil and me are now trying to replace the ST RAM routines
and use standard erase/write BL commands, instead of using the GO
command. Reason is that jumping back to BL after a GO command is
unreliably and apparently not intendended by STM.
Unfortunately passing of parameters between ROM BL and RAM routines is
not documented, so I am currently reverse-engineering this. Progress is
slow but we'll get there... :-)
Thanks again!
Georg
Am 05.12.20 um 08:11 schrieb Hynek Sladký:
Hi,
I tried to study bootloader code a bit...
As far as I can see there, 'Go' command in bootloader jumps to user
code using JPF [0x8A] instruction; at 0x8A it stores 24-bit part of
received address. There is no official support for return to bootloader...
But what about jumping back to 0x6000 address to start bootloader
again? Or maybe use illegal instruction opcode to force MCU to reset?
Bootloader does some measurement and calculation for getting real
communication speed. Results are stored in RAM but I am not sure if
these values are retained after bootloader finishes.
BR,
Hynek
Dne 28.11.2020 v 08:19 Georg Icking-Konert napsal(a):
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
- 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
_______________________________________________
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
