• State Not Answered
  • Replies 3 replies
  • Subscribers 65 subscribers
  • Views 163 views
  • Users 0 members are here
Attachments (0)
Nordic Case Info
  • Case ID: 328965
Options

flash: spi_nor: JEDEC ID not always reading correctly

dan_opito

Hi,

Our custom hardware makes use of an external flash device, IS25LP032D-JTLE-TR, for storing files (littlefs) and OTA updates. We've noticed, seemingly only after a power-on reset, that we're unable to initiatlise the flash. The error reported is <err> spi_nor: Device id 00 00 00 does not match config 9d 60 16 - but simply hitting the reset button (or detecting -ENODEV from littlefs and rebooting in software) is enough to fix it.

We're rather out-of-date with Zephyr and NCS - we're running SDK 2.2.0, and a Zephyr kernel with a few backports (you can see our tree here: opito-nz/sdk-zephyr: NCS downstream of https://github.com/zephyrproject-rtos/zephyr). I have cherry-picked some interesting looking commits, however none seem to resolve the issue.

I also went through devzone and noticed many with the JEDEC ID error are always seeing this - we only see it after a power-on reset. My theory, then, is something to do with how long Zephyr waits before attempting to talk to the flash. I added a one millisecond delay to spi_nor_configure() without much luck - and no other errors, for example with reading the status register, are reported. I haven't tried probing the data lines to see if there are any bits at all (and SPI is misreading) - but probing this design will be challenging as I need to solder to the USON package (i.e. similar to QFN).

I tried increasing t-enter-dpd and t-exit-dpd (from 3 us to 30 us) with no change.

We're about to get another batch of devices, with the nRF9151, and are using the same flash device. My work around for now is detecting the -ENODEV and rebooting our firmware. It's inelegant but it seems to work.

Kind regards,

Dan

Parents
  • 0

    Hello,

    If introducing a blocking delay, such as k_busy_wait(), resolves the initialization issue for your external flash device, it suggests that the flash device indeed needs additional time to be ready after a power-on reset. k_sleep(): This function puts the calling thread to sleep for a specified duration. During this sleep period, the CPU can perform other tasks, making it a non-blocking delay.k_busy_wait(): This function creates a blocking delay where the CPU is actively waiting for the specified duration, and it doesn't perform other tasks during this period.

    I will look into your implementation.

    Kind Regards,

    Abhijith

Reply
  • 0

    Hello,

    If introducing a blocking delay, such as k_busy_wait(), resolves the initialization issue for your external flash device, it suggests that the flash device indeed needs additional time to be ready after a power-on reset. k_sleep(): This function puts the calling thread to sleep for a specified duration. During this sleep period, the CPU can perform other tasks, making it a non-blocking delay.k_busy_wait(): This function creates a blocking delay where the CPU is actively waiting for the specified duration, and it doesn't perform other tasks during this period.

    I will look into your implementation.

    Kind Regards,

    Abhijith

Children
No Data
Related