same54_xplained fails to boot starting from CPY 8.2.0 #10172
Comments
|
The same issue is observed with CPY 9.2.6 and GCC13; I had to apply the patch below first: diff --git a/samd/dma.c b/samd/dma.c
index 4925942..50a2cdb 100644
--- a/samd/dma.c
+++ b/samd/dma.c
@@ -64,9 +64,12 @@ uint8_t dma_allocate_channel(bool audio_channel) {
}
void dma_free_channel(uint8_t channel) {
- assert(dma_allocated[channel]);
- dma_disable_channel(channel);
- dma_allocated[channel] = false;
+ if (dma_allocated[channel]) {
+ dma_disable_channel(channel);
+ dma_allocated[channel] = false;
+ }
+
+ return;
} |
|
@EmergReanimator CircuitPython is built and tested with the GCC 13.3.Rel1 toolchain found here: https://developer.arm.com/downloads/-/arm-gnu-toolchain-downloads. This toolchain includes patches specific to ARM cores. Is this the source of the toolchain you are using? |
|
So maybe Another possibility, but maybe less likely in this case. In |
|
@EmergReanimator How did you arrrive at that patch? |
It does assert during the initialisation when built with DEBUG=1.
This was the reason for my patch. |
With gcc 14 only, or also with gcc 13? |
In fact it is another compiler independent issue: |
|
The GDB traceback looks like it might be a GCC code gen problem, which is why I asked about the toolchain. The patches from ARM sometimes take quite a while to get upstream into a GCC release. |
I have used arm-none-eabi-gcc (Fedora 14.1.0-2.fc41) 14.1.0 by default (GCC14). I have just tried the ARM GCC 13.3* and CPY 9.2.6 without success. The CPY hangs in * arm-none-eabi-gcc (Arm GNU Toolchain 13.3.Rel1 (Build arm-13.24)) 13.3.1 20240614 |
|
@EmergReanimator Thanks for verifying that! |
|
Here is the short summary of my results.
❗ - unstable, succeeded just once
|
|
FYI CPY 9.0.0 runs fine with FS stubs built with GCC 14: diff --git a/ports/atmel-samd/boards/same54_xplained/mpconfigboard.mk b/ports/atmel-samd/boards/same54_xplained/mpconfigboard.mk
index d5038030e4..7263398e37 100644
--- a/ports/atmel-samd/boards/same54_xplained/mpconfigboard.mk
+++ b/ports/atmel-samd/boards/same54_xplained/mpconfigboard.mk
@@ -6,9 +6,12 @@ USB_MANUFACTURER = "Microchip"
CHIP_VARIANT = SAME54P20A
CHIP_FAMILY = same54
-QSPI_FLASH_FILESYSTEM = 1
-EXTERNAL_FLASH_DEVICES = "N25Q256A,SST26VF064B"
+# QSPI_FLASH_FILESYSTEM = 1
+# EXTERNAL_FLASH_DEVICES = "N25Q256A,SST26VF064B"
LONGINT_IMPL = MPZ
CIRCUITPY_SDIOIO = 1
CIRCUITPY_CANIO = 1
+CIRCUITPY_FULL_BUILD = 0
+DISABLE_FILESYSTEM = 1
+CIRCUITPY_USB_MSC = 0
|
|
@EmergReanimator Very useful information throughout. I'm focusing on the flash filesystem code but will be delayed a few days waiting for some test parts to arrive. |
EmergReanimator
changed the title
|
I narrowed down the root cause: |
|
@EmergReanimator Diff'ing the 8.1.0 and 8.2.0 tags I see the SST26VF064B was added to the list of possible flash parts. What is the flash part # on your board? |
|
Possibly same as #8047. The file |
|
The SST26VF064B part requires that the IOC bit in its configuration register be set to 1 before quad read/write operations will succeed. There are two flavors of the SST26VF064, one with a B suffix the other with a BA suffix. The B suffix parts (the one shown in the photo in #8047) POR with this bit set to 0.
|
|
check_quad_enable can write two bytes to the status register, which seems to be how the configuration register is written (see 5.30 in the datasheet). I think this'll make it write 00 02 which should set IOC: (to be updated in total guess, didn't test anything. |
|
@jepler That might work. Thanks for taking the time to have a look. I'll desk check and PR if it looks OK. |
|
@jepler 's suggestion desk checks. The only crunchy bit is in circuitpython/supervisor/shared/external_flash/external_flash.c Lines 238 to 248 in a0b482c Here we'll read the configuration register at lines 244-246 and test the WPEN (Write Protection Pin Enable) bit. This should always be 0, so although we're not actually testing for a suspended write/erase, we should fall through safely.
|
|
@EmergReanimator Please make the change noted above by @jepler to |
I have got a SAME54 Xplained board with 26F064B flash.
The commit adafruit/nvm.toml@9dc99a2 did not help. Oddly enough, but the 8.2.9 boots fine when external flash is set to
diff --git a/data/nvm.toml b/data/nvm.toml
--- a/data/nvm.toml
+++ b/data/nvm.toml
@@ -1 +1 @@
-Subproject commit 6b678f15e378edce820f2ffdef3286b3e55449e7
+Subproject commit 6b678f15e378edce820f2ffdef3286b3e55449e7-dirty
diff --git a/ports/atmel-samd/boards/same54_xplained/mpconfigboard.mk b/ports/atmel-samd/boards/same54_xplained/mpconfigboard.mk
index d5038030e4..53aac7df2a 100644
--- a/ports/atmel-samd/boards/same54_xplained/mpconfigboard.mk
+++ b/ports/atmel-samd/boards/same54_xplained/mpconfigboard.mk
@@ -7,7 +7,7 @@ CHIP_VARIANT = SAME54P20A
CHIP_FAMILY = same54
QSPI_FLASH_FILESYSTEM = 1
-EXTERNAL_FLASH_DEVICES = "N25Q256A,SST26VF064B"
+EXTERNAL_FLASH_DEVICES = "N25Q256A"
LONGINT_IMPL = MPZ
CIRCUITPY_SDIOIO = 1 |
|
@EmergReanimator Thank you for your patience and persistence. I've updated the I suspect there's a deeper problem in |
Why the flash is ready when the WEL is cleared? diff --git a/supervisor/shared/external_flash/external_flash.c b/supervisor/shared/external_flash/external_flash.c
index f72518ac50..f505408786 100644
--- a/supervisor/shared/external_flash/external_flash.c
+++ b/supervisor/shared/external_flash/external_flash.c
@@ -70,7 +70,7 @@ static bool wait_for_flash_ready(void) {
uint8_t read_status_response[1] = {0x00};
do {
ok = spi_flash_read_command(CMD_READ_STATUS, read_status_response, 1);
- } while (ok && (read_status_response[0] & 0x3) != 0);
+ } while (ok && (read_status_response[0] & 0x1) != 0x0);
return ok;
}
|
|
That code bothered me, too. Are you running with this as the only change? Does the CIRCUITPY device mount with a size < 8MB? |
The code is intended to be generic for all of the flash devices CP supports. I suspect it's there for one or more of the other 600+ boards we support. I read it as handling a reset when the flash chip was busy with a lengthy programming operation. |
8.4 MB (8 MiB) to be precise. |
That one too. |
|
Perfect. I'll PR a more general solution later that includes the |
Yes, you can say so. @eightycc Thanks for your eager support! Just for your information: |
CircuitPython version and board name
Code/REPL
Behavior
Not applicable
Description
CPY stucks in file system initialisation when built with GCC14.
The same code works fine if it is compiled with GCC10;
Tried the tag 9.0.0;
Here is the back trace of problematic code. Currently no idea what exactly goes wrong here.
Additional information
No response
The text was updated successfully, but these errors were encountered: