Hi Eric,
having thought this over, I see pros and cons for both options.
Therefore I have just started a discussion under
https://github.com/gicking/stm8-bootloader-erase-write/discussions to
collect arguments.
Georg
Am 08.12.20 um 08:58 schrieb Eric Rullens:
Hi Georg,
Yes, that is exact
d 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
h
re 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
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
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 parameter
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
hi Philipp,
good point, I will keep that in mind.
However, currently my main issue is that returning to the bootloader
messes up the UART baudrate (see my last post) - even using a dummy RAM
doutine with only return. So any communication afterwards fails. Any idea?
Georg
Am 28.11.20 um 08:
Am 28.11.20 um 00:48 schrieb Basil Hussain:
> So, if you don't want to disturb or conflict with the bootloader
> operations, you should probably avoid that entire initial 512 bytes for
> static/global variables. I guess you could use the '__at' syntax to
> assign specific addresses for any variable
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
I did some more tests and seemingly the RAM program fails if I
overwrite certain addresses. My theory is that the ROM bootloader
requires these and thus fails if I overwrite them. But it's a pretty
weak theory, because I feel it fails for too many RAM addresses. Hmmm...
Have you seen section
hello all,
I did some more tests and seemingly the RAM program fails if I overwrite
certain addresses. My theory is that the ROM bootloader requires these
and thus fails if I overwrite them. But it's a pretty weak theory,
because I feel it fails for too many RAM addresses. Hmmm...
In a simil
Am 24.11.20 um 19:01 schrieb Georg Icking-Konert:
> hello again again,
>
> sorry for flooding you with this issue but I have good news!
>
> As I don't know where SDCC / STM8 store stack, heap etc. in RAM, I
> thought I'd better stay away from the borders. Seemingly that was a bad
> idea, because
hello again,
I did a few more tests and it seems like ROM bootloader and stm8gal
function properly. Here is what I did:
1) program a "fast blink" program to 0x8000 (checked in map and ihx file)
2) compile/link a "slow blink" for 0x9000 (checked in map and ihx file)
3) manually removed
hello again again,
sorry for flooding you with this issue but I have good news!
As I don't know where SDCC / STM8 store stack, heap etc. in RAM, I
thought I'd better stay away from the borders. Seemingly that was a bad
idea, because if I replace 0xa0 in Makefile by 0x00 (start of RAM), it
wor
Hi Basil,
attached please find the project with output. Maybe you find something.
File "main_RAM.ihx" was manually created by removing all lines in
"main.ihx" with address in flash.
I tested this with a Sduino Uno board
(https://github.com/roybaer/sduino_uno) and used stm8gal for uploading
However, even when I correct the jump address from main.map the LED
doesn't blink. Then I included the delay loop into main() to avoid
function calls altogether (->main now at 0xa0), but still no blinking.
Darn!
Hmm, if that's the case now, hard to say.
I don't have STM8 hardware on hand r
Am 22.11.20 um 07:23 schrieb Georg Icking-Konert:
> - any proposal how I to share files without attaching them to this
> newsletter? Thanks!
The mailing list is more popular and active, but SDCC does also have a
support request tracker, that allows file attachments (the interface is
like the on
Hi,
thanks a lot for the hint, your observation is 100% correct!
However, even when I correct the jump address from main.map the LED
doesn't blink. Then I included the delay loop into main() to avoid
function calls altogether (->main now at 0xa0), but still no blinking. Darn!
Any idea what c
Hi,
I think I know why your code isn't working as expected.
If your example code is compiled and linked as specified, but we walk
through normal execution - as if it had been programmed and booted
normally - the flow from power-on goes as follows:
1. 0x8000 - Beginning of flash; executes res
hello,
I want to write a STM8 program which is executed from RAM. But unlike
the example in
https://lujji.github.io/blog/executing-code-from-ram-on-stm8/ it is not
stored in flash and copied to RAM during runtime. Instead the hexfile is
uploaded to RAM via the ROM bootloader, and then invoked
20 matches
Mail list logo
