hi Eric,
the STM8 ROM bootloader does all the protocol handling and device
specific tests. Only the actual write and erase is executed from RAM.
The routines for this have to be uploaded to RAM first. This is
described in the STM8 bootloader manual (UM0560). The repective hexfiles
for various devices are available from the ST homepage. However, as
Phillip pointed out, they are not OS but under a proprietary ST license.
Unfortunately the parameter passing from/to ROM<->RAM is not documented,
so we have to reverse engineer it.
But I guess that's not your question...!? If I understand correctly you
propose to use the ROM-BL only to upload a custom RAM bootloader which
then handles the communication, write/erase etc.. IMHO the main obstacle
is RAM size. As far as I can see the smallest device with ROM-BL has 1kB
of RAM, the biggest 6kB. The smaller ones only support UART, the larger
ones UART, SPI and CAN.
But apart from that I like the idea! Let me think about this and play
around a bit. If it can be made to fit RAM, that would also solve
another issue, namely that read-out in "UART reply mode" is extremly
slow :-)
Georg
Am 07.12.20 um 21:04 schrieb Eric Rullens:
Just a question on this topic: why use the STM8 built-in bootloader routines
at all (other than for bootstrapping your own bootloader code)?
The flash/EEPROM controller is documented in the reference manual(s) and it
is very easy to code the few instructions that are required for erase/write
control.
Eric
________________________________
From: Georg Icking-Konert [mailto:ge...@cream-tea.de]
Sent: zaterdag 5 december 2020 08:55
To: sdcc-user@lists.sourceforge.net; Hynek Sladký
Subject: Re: [Sdcc-user] RAM program
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
<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
