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
<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