Hi Georg, Yes, that is exactly what I mean: load your own loader code in RAM and from there you are free to do as you please. For example use a more efficient protocol, and/or change to (higher) baudrates that are not supported by the built-in bootloader.
I do this for NXP LPC and STM32 controllers and it works very well (adding STM8 is on the wish list, but not with high priority at the moment). I would not bother trying to write a "one size fits all" bootloader, just make specialized ones for UART, SPI, CAN as required. Even 1 kB of RAM should be plenty this way. Aside from internal flash I also added loaders that can program external EEPROM or serial flash. This is quite convenient to have. In my case all the loaders have an option to reset the chip and restart the built-in bootloader, so the whole process can be repeated (e.g. to first program an external EEPROM and then the internal flash). Eric -----Oorspronkelijk bericht----- Van: Georg Icking-Konert [mailto:ge...@cream-tea.de] Verzonden: dinsdag 8 december 2020 07:41 Aan: Eric Rullens; 'sdcc-user@lists.sourceforge.net'; Hynek Sladký CC: Basil Hussain Onderwerp: Re: [Sdcc-user] RAM program 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
