stbenn commented on issue #16416: URL: https://github.com/apache/nuttx/issues/16416#issuecomment-2946545060
@raiden00pl Thanks for the suggestion! I have not used any of the TZ features, and they are all disabled but that doesn't mean they aren't causing an issue. I briefly looked into them and nothing jumped out that could be causing this, but I could have missed something. For some more info that I have gathered in the last week or two: **On the H5**, it appears to be a "Double Fault" judging by the GDB logs. I looked into it a bit further, and I see a flash double ECC error occur during the copy from flash to ram in the start function. Very strangely, the address recorded for the error is outside of the bounds (or _should be_) of the copy. When the fault occurs, `FLASH_ECCDETR::ADDR_ECC = 0x3300` (Least significant 16 bits of address where first double ECC error occurs). However, the map suggests the memory copy should correspond to these ranges: - FLASH: `[0x08032f24, 0x080332a8)` - SRAM: `[0x20000000, 0x10000384)` This leads me to think that maybe FLASH isn't getting cleared properly before write during debug when banks are swapped, or some hardware mechanism/bug. **On the G0B1RE**, debug immediately fails and does not even get to `__start()`. Could there be something wrong with the linker scripts of these chips that would cause this behavior when banks are swapped? I am not very familiar with linker scripts, and both of the boards that I put the linker scripts for (H5 and G0B1RE) fail during debug when banks are swapped. I want to believe this is a coincidence, but I would like to verify if possible. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: commits-unsubscr...@nuttx.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org
