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

Reply via email to