Zeptoforth doesn't recover after compile-to-flash and reset

[robzed]

When I do this:

compile-to-flash
#include WiFiNINA_gpio.fth

After a reboot (using the reset button), it never comes back to the Forth prompt - it's just frozen.

Here is the file: https://github.com/robzed/ukmarsbot_forth/blob/master/for_rp2040/WiFiNINA_gpio.fth

Maybe it's my use of buffer:? I don't see anything else special in this code.

Follow up questions:

• Is there a recovery mechanism to get Zeptoforth back to a running state - or is re-flashing Zeptoforth with BOOTSEL the best option?
• If buffer: is indeed the problem, is there way to stop us compiling illegal operations?

[tabemann]

Actually, I flashed this code to my Pico W and it booted just fine afterwards. The only hitch is that after you reboot and you had compiled code to flash beforehand, the board will not respond immediately as it is regenerating the flash dictionary index, so immediately after rebooting trying to use /dev/ttyACM0 or like will fail.

[robzed]

I tried on it on Arduino Nano RP2040 Connect - but figured it was maybe a problem with the 16MB flash. So I tried with a Raspberry Pi Pico. Same result.

Version used: zeptoforth_full-1.1.0.uf2

Executed:

compile-to-flash
#include WiFiNINA_gpio.fth

End of Terminal Window:

;  ok
: analogWrite ( pin value0-255 -- )  ok
SET_ANALOG_WRITE _send2  ok
TempReturnBuf 1 SET_ANALOG_WRITE _rcv drop  ok
;  ok
6 constant WL_FW_VER_LENGTH  ok
WL_FW_VER_LENGTH buffer: FwVersionCStr  ok
: getFwVersion ( -- versionstr vlen )  ok
SPI_wait_for_SS  ok
0 GET_FW_VERSION_CMD SPI_send_cmd  ok
SPI_NINA_deselect  ok
SPI_wait_for_NINA_ready  ok
SPI_NINA_select  ok
FwVersionCStr dup 1 GET_FW_VERSION_CMD SPI_get_response_cmd  ok
SPI_NINA_deselect  ok
;  ok
end-module  ok
  ok
  ok
  ok
reboot 

Sits there many minutes... no change.

[robzed]

Never recovers - even after reboot.
Need to reflash with Zeptoforth image.

I was going to test:

WL_FW_VER_LENGTH word-align buffer: FwVersionCStr

(this doesn't exactly feel like the right word - but it doesn't exist!!! it's in basic.md)

Did this instead:

WL_FW_VER_LENGTH 4 align buffer: FwVersionCStr

End of Terminal:

6 constant WL_FW_VER_LENGTH  ok
WL_FW_VER_LENGTH 4 align buffer: FwVersionCStr  ok
: getFwVersion ( -- versionstr vlen )  ok
SPI_wait_for_SS  ok
0 GET_FW_VERSION_CMD SPI_send_cmd  ok
SPI_NINA_deselect  ok
SPI_wait_for_NINA_ready  ok
SPI_NINA_select  ok
FwVersionCStr dup 1 GET_FW_VERSION_CMD SPI_get_response_cmd  ok
SPI_NINA_deselect  ok
;  ok
end-module  ok
Reboot

Welcome to zeptoforth
Built for rp2040, version 1.1.0, on Mon Sep 11 07:21:28 PM CDT 2023
zeptoforth comes with ABSOLUTELY NO WARRANTY: for details type `license'
 ok

So this works?!?!

There isn't any data definition after this (a single word defined) as you can see.

Do I need a ram-align or flash-align, at the end of the file?

I added both at the end of the file and it crashes during compile?!?!?!?

        SPI_NINA_deselect
    ;

end-module
flash-align,
ram-align,

Terminal

2 = IF  ok
TempReturnBuf h@  ok
ELSE  ok
cr ." Unexpected return" cr  ok
0  ok
THEN  ok
;  ok
: analogWrite ( pin value0-255 -- )  ok
SET_ANALOG_WRITE _send2  ok
TempReturnBuf 1 SET_ANALOG_WRITE _rcv drop  ok
;  ok
6 constant WL_FW_VER_LENGTH  ok
WL_FW_VER_LENGTH buffer: FwVersionCStr  ok
: getFwVersion ( -- versionstr vlen )  ok
SPI_wait_for_SS  ok
0 GET_FW_VERSION_CMD SPI_send_cmd  ok
SPI_NINA_deselect  ok
SPI_wait_for_NINA_ready  ok
SPI_NINA_select  ok
FwVersionCStr dup 1 GET_FW_VERSION_CMD SPI_get_response_cmd  ok
SPI_NINA_deselect  ok
;  ok
end-module  ok
flash-align, 

[robzed]

Ok, flash-align, and ram-align, take a parameter... DOH!

TempReturnBuf 1 SET_ANALOG_WRITE _rcv drop  ok
;  ok
6 constant WL_FW_VER_LENGTH  ok
WL_FW_VER_LENGTH buffer: FwVersionCStr  ok
: getFwVersion ( -- versionstr vlen )  ok
SPI_wait_for_SS  ok
0 GET_FW_VERSION_CMD SPI_send_cmd  ok
SPI_NINA_deselect  ok
SPI_wait_for_NINA_ready  ok
SPI_NINA_select  ok
FwVersionCStr dup 1 GET_FW_VERSION_CMD SPI_get_response_cmd  ok
SPI_NINA_deselect  ok
;  ok
end-module  ok
4 flash-align,  ok
4 ram-align,  ok
reboot 

This also doesn't recover after a reboot.

[tabemann]

@robzed I found the problem:

    \ firmware version string length
    6 constant WL_FW_VER_LENGTH

    WL_FW_VER_LENGTH buffer: FwVersionCStr

should be:

    \ firmware version string length
    6 constant WL_FW_VER_LENGTH

    WL_FW_VER_LENGTH 4 align buffer: FwVersionCStr

Now I have:

    \ firmware version string length  ok
    6 constant WL_FW_VER_LENGTH  ok
  ok
    WL_FW_VER_LENGTH 4 align buffer: FwVersionCStr  ok
  ok
    : getFwVersion ( -- versionstr vlen )  ok
        SPI_wait_for_SS  ok
        0 GET_FW_VERSION_CMD SPI_send_cmd  ok
  ok
        SPI_NINA_deselect  ok
  ok
  ok
        \ Wait the reply elaboration  ok
        SPI_wait_for_NINA_ready  ok
        SPI_NINA_select  ok
        \ ." Wait reply" CR  ok
        FwVersionCStr dup 1 GET_FW_VERSION_CMD SPI_get_response_cmd  ok
        SPI_NINA_deselect  ok
    ;  ok
  ok
end-module  ok
  ok
  ok
\ #test items  ok
\   ok
\ WiFiNINA import   ok
\ enable_NINA  ok
\ getFwVersion .s cr type cr  ok
\  ok
\ NinaPin_LEDB 1 pinMode .s  ok
\ NinaPin_LEDB 1 digitalWrite  ok
\ NinaPin_LEDB 0 digitalWrite  ok
\   ok
\ NinaPin_LEDG pinModeOUTPUT  ok
\ NinaPin_LEDG 1 digitalWrite  ok
\ NinaPin_LEDG 0 digitalWrite  ok
\   ok
\ NinaPin_LEDR pinModeOUTPUT  ok
\ NinaPin_LEDR 1 digitalWrite  ok
\ NinaPin_LEDR 0 digitalWrite  ok
  ok
\ NinaPin_LEDR digitalRead .  ok
  ok
\ 4 analogRead .  ok
\ 5 analogRead .   ok
\ 6 analogRead .  ok
\ 7 analogRead .  ok
  ok
\ NinaPin_LEDB 0 analogWrite  ok
\ NinaPin_LEDB 128 analogWrite  ok
\ NinaPin_LEDB 255 analogWrite  ok
  ok
\ NinaPin_LEDR 0 analogWrite  ok
\ NinaPin_LEDR 128 analogWrite  ok
\ NinaPin_LEDR 255 analogWrite  ok
  ok
\ NinaPin_LEDG 0 analogWrite  ok
\ NinaPin_LEDG 128 analogWrite  ok
\ NinaPin_LEDG 255 analogWrite  ok
reboot 
Welcome to zeptoforth
Built for rp2040, version 1.1.0, on Mon Sep 11 07:21:28 PM CDT 2023
zeptoforth comes with ABSOLUTELY NO WARRANTY: for details type `license'
 ok

The original code was causing alignment issues, which was causing zeptoforth to crash on bootup before it could even bring up the REPL. Alignment issues are, well, troublesome on the RP2040 due to it being a Cortex-M0+ and thus requiring aligned accesses.

[tabemann]

I have now mentioned alignment as a major gotcha in the wiki.

[tabemann]

One important note, though - unless you are very careful, try to make buffers' sizes multiples of four bytes to avoid alignment issues. Some things will work correctly when compiling to RAM will not work when compiled to flash because in many cases compiling to RAM forces alignment when compiling to flash does not.

[robzed]

This is logical, but could easily be missed since it's not mentioned in the documentation.

"compiling to flash forces alignment when compiling to flash does not."
Which one is compiling to RAM in this sentence?

[tabemann]

Okay, I just corrected my comment above. Compiling to RAM forces alignment because word headers compiled to RAM force alignment but compiling to flash does not because the word headers live in flash but the RAM space for said words, of course, lives separate from said word headers and thus the word headers do not ensure alignment.

Yes, this should go somewhere in the docs, but I am not sure where to put it that anyone would notice it.

[Andy2No]

Would it be appropriate for compiling to flash to force alignment too, or would that cause other problems?

It would be nice to be able to go from code working in RAM to code also working in flash, without having to check through it all to manually adjust the alignment.

I like the idea of being able to work in RAM, to save write cycles on the flash, but I'd also like to be able to make code that runs from turning a device on, without that being overly difficult to do. Since a mistake in adjusting alignment would appear to mean re-flashing, that could take quite a few attempts to get right and would lose some of the advantages of less wear on the flash.

[tabemann]

if compilation to flash forced alignment, it would be impossible to have words such as cvariable and hvariable, which allot space in RAM, which fit in space of less than one cell. To be completely honest, though, I would not use these unless you feel the overriding need to save a few bytes at a time.

Of course, when using these words one has to be careful to ensure alignment. Note that there are other areas where alignment comes into play. For instance, there are the words aligned-buffer: to ensure cell-aligned buffers in RAM and with-aligned-allot to ensure cell-aligned buffers in the current task's RAM dictionary.

Other things one can do are to align buffer sizes with cell align (note that the equivalent of ANS align in zeptoforth is actually cell align,), which takes a value and then rounds it up to the nearest power of four.

Another matter is that structure fields specifically are not aligned, because structures are oftentimes meant to fit a predefined data structure format one has no control over, such as IPv4 packet headers. In these cases it is up to the programmer to ensure safe access to the data structure.