New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fill flash .ihx files with 00 #84

Closed
barewires opened this Issue Oct 1, 2017 · 9 comments

Comments

Projects
None yet
2 participants
@barewires

barewires commented Oct 1, 2017

Just updated W1209 to 2.2.17 and dumped flash and saw all remnants of previous words in the dictionary. How about padding the remaining 3K flash with 00 for readability?

I thought about writing another memory to intel hex file converter (how many times I've done that since the mid 70s, but time is running out for me). So I read -r a new blank chip with
./stm8flash -c stlinkv2 -p stm8s003?3 -s flash -r newblankchip.ihx
and had my empty flash template within seconds.

Every new programmer should do it at least once.

@TG9541

This comment has been minimized.

Show comment
Hide comment
@TG9541

TG9541 Oct 1, 2017

Owner

If you look into the code of simload.sh you'll see that there is already code for creating zero-padded hex files. (right, this wasn't the first time I had to write some hex file manipulation code :-) )

# gawk: uCsim "dch" dump to Intel HEX conversion
read -d '' makeHex << 'EOF'
/^0x/ {
  cs=0; a=":"; g=$0; n=gsub(/ 0x/,"",g)
  App(Xpr(n),1); App($1,4); App($1,6); App("00",1)
  for (i=2; i<=(n+1); i++) { App($i,3) }
  print a Xpr(and(-cs,0xFF))
}
END { print ":00000001FF" }
function Xpr(x) { return sprintf("%02x",x) }
function App(x,n) {
  s=substr(x,n,2); a=a s; cs+=strtonum("0x" s)
}
EOF

@barewires do you think that it would be best always release zero-padded hex files? I wasn't sure if that's always what people expect, and I was even thinking about writing a filter for stripping hex files.

Owner

TG9541 commented Oct 1, 2017

If you look into the code of simload.sh you'll see that there is already code for creating zero-padded hex files. (right, this wasn't the first time I had to write some hex file manipulation code :-) )

# gawk: uCsim "dch" dump to Intel HEX conversion
read -d '' makeHex << 'EOF'
/^0x/ {
  cs=0; a=":"; g=$0; n=gsub(/ 0x/,"",g)
  App(Xpr(n),1); App($1,4); App($1,6); App("00",1)
  for (i=2; i<=(n+1); i++) { App($i,3) }
  print a Xpr(and(-cs,0xFF))
}
END { print ":00000001FF" }
function Xpr(x) { return sprintf("%02x",x) }
function App(x,n) {
  s=substr(x,n,2); a=a s; cs+=strtonum("0x" s)
}
EOF

@barewires do you think that it would be best always release zero-padded hex files? I wasn't sure if that's always what people expect, and I was even thinking about writing a filter for stripping hex files.

@TG9541 TG9541 self-assigned this Oct 1, 2017

@TG9541 TG9541 added the enhancement label Oct 1, 2017

@barewires

This comment has been minimized.

Show comment
Hide comment
@barewires

barewires Oct 1, 2017

New to eForth, as we all are, I see no reason not to have a fully padded hex file. For the sake of readability, as we are trying to learn the dictionary structure and disassembling the stm8 code, I would like to see it. 3K of added blank code is a lot more eForth friendly than writing any more filters or utilities on a host machine. I suppose a library of eForth words will eventually be available, but I am on my last legs. End of Line (Tron). lol

barewires commented Oct 1, 2017

New to eForth, as we all are, I see no reason not to have a fully padded hex file. For the sake of readability, as we are trying to learn the dictionary structure and disassembling the stm8 code, I would like to see it. 3K of added blank code is a lot more eForth friendly than writing any more filters or utilities on a host machine. I suppose a library of eForth words will eventually be available, but I am on my last legs. End of Line (Tron). lol

@TG9541

This comment has been minimized.

Show comment
Hide comment
@TG9541

TG9541 Oct 1, 2017

Owner

I think that this will work in most situations:

nvm here $a000 over - erase ram
Owner

TG9541 commented Oct 1, 2017

I think that this will work in most situations:

nvm here $a000 over - erase ram
@TG9541

This comment has been minimized.

Show comment
Hide comment
@TG9541

TG9541 Oct 2, 2017

Owner

@barewires there are good reasons for zero-padding hex files, but there are also reasons against it:

  • it overwrites any persistent data
  • similar µCs with different Flash size require additional binaries

Workarounds:

  1. using Forth: nvm here $a000 over - erase ram
  2. write zeros to the device
dd if=/dev/zero count=16 >zero.bin
stm8flash -c stlinkv2 -p stm8s103f3 -s flash -w zero.bin
  1. (now it gets interesting) set and then clear the Read-out-Protection (ROP)
echo "aa 00 ff 00 ff 00 ff 00 ff 00 ff" | xxd -r -p > rop.bin
stm8flash -c stlinkv2 -p stm8s103f3 -s opt -w rop.bin
echo "00 00 ff 00 ff 00 ff 00 ff 00 ff" | xxd -r -p > defaults.bin
stm8flash -c stlinkv2 -p stm8s103f3 -s opt -w defaults.bin

By the way, setting the ROP is a bit pointless if there is a Forth console.
Password protected Forth console, anyone?

Since working around the issue is rather simple, I won't fix it.

Owner

TG9541 commented Oct 2, 2017

@barewires there are good reasons for zero-padding hex files, but there are also reasons against it:

  • it overwrites any persistent data
  • similar µCs with different Flash size require additional binaries

Workarounds:

  1. using Forth: nvm here $a000 over - erase ram
  2. write zeros to the device
dd if=/dev/zero count=16 >zero.bin
stm8flash -c stlinkv2 -p stm8s103f3 -s flash -w zero.bin
  1. (now it gets interesting) set and then clear the Read-out-Protection (ROP)
echo "aa 00 ff 00 ff 00 ff 00 ff 00 ff" | xxd -r -p > rop.bin
stm8flash -c stlinkv2 -p stm8s103f3 -s opt -w rop.bin
echo "00 00 ff 00 ff 00 ff 00 ff 00 ff" | xxd -r -p > defaults.bin
stm8flash -c stlinkv2 -p stm8s103f3 -s opt -w defaults.bin

By the way, setting the ROP is a bit pointless if there is a Forth console.
Password protected Forth console, anyone?

Since working around the issue is rather simple, I won't fix it.

@TG9541 TG9541 closed this Oct 2, 2017

@TG9541 TG9541 added wontfix and removed enhancement labels Oct 2, 2017

@barewires

This comment has been minimized.

Show comment
Hide comment
@barewires

barewires Oct 2, 2017

There is no LOCKF and ULOCKF in 2.2.16
nvm here $a000 over - erase ram, does not work for flash. I need to do more testing.

barewires commented Oct 2, 2017

There is no LOCKF and ULOCKF in 2.2.16
nvm here $a000 over - erase ram, does not work for flash. I need to do more testing.

@barewires

This comment has been minimized.

Show comment
Hide comment
@barewires

barewires Oct 2, 2017

pi@raspberrypiDrive:~ $ dd if=/dev/zero count=8192 >zero.bin
8192+0 records in
8192+0 records out
4194304 bytes (4.2 MB) copied, 0.103575 s, 40.5 MB/s
Looks to be a bit bigger than 8K, LOL

barewires commented Oct 2, 2017

pi@raspberrypiDrive:~ $ dd if=/dev/zero count=8192 >zero.bin
8192+0 records in
8192+0 records out
4194304 bytes (4.2 MB) copied, 0.103575 s, 40.5 MB/s
Looks to be a bit bigger than 8K, LOL

@TG9541

This comment has been minimized.

Show comment
Hide comment
@TG9541

TG9541 Oct 2, 2017

Owner

Ah, dd uses blocks :D
Please try dd if=/dev/zero count=16 >zero.bin

nvm here $a000 over - erase ram works for me. It's intended to be used after flashing the device, or after running reset.

I removed LOCKF and ULOCKF because I felt that for most use cases it's redundant (RAM and NVM should do the job for most use cases).

Do you think that it should be part of the default dictionary?

Owner

TG9541 commented Oct 2, 2017

Ah, dd uses blocks :D
Please try dd if=/dev/zero count=16 >zero.bin

nvm here $a000 over - erase ram works for me. It's intended to be used after flashing the device, or after running reset.

I removed LOCKF and ULOCKF because I felt that for most use cases it's redundant (RAM and NVM should do the job for most use cases).

Do you think that it should be part of the default dictionary?

@barewires

This comment has been minimized.

Show comment
Hide comment
@barewires

barewires Oct 2, 2017

Thanks for the comprehensive follow-ups. I haven't used dd 'Disk Destroyer' in years.
here equates to $A0 but I now understand it and the importance of nvm...ram
I agree the issue is closed.
Let me send you a donation of Mindev boards, STM8S001 and a handfull of cat detectors RCWL-0516 for your troubles.

barewires commented Oct 2, 2017

Thanks for the comprehensive follow-ups. I haven't used dd 'Disk Destroyer' in years.
here equates to $A0 but I now understand it and the importance of nvm...ram
I agree the issue is closed.
Let me send you a donation of Mindev boards, STM8S001 and a handfull of cat detectors RCWL-0516 for your troubles.

@TG9541

This comment has been minimized.

Show comment
Hide comment
@TG9541

TG9541 Oct 2, 2017

Owner

Could it be that "here equates to $A0" is related to #85? v2.2.17 has just been released to fix it (hopefully the next release will add a release number to the HI string).

Keeping me on a learning curve is difficult enough for users of this tiny Forth.

Owner

TG9541 commented Oct 2, 2017

Could it be that "here equates to $A0" is related to #85? v2.2.17 has just been released to fix it (hopefully the next release will add a release number to the HI string).

Keeping me on a learning curve is difficult enough for users of this tiny Forth.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment