Electric IMP003 SPI Flash Error

Hardware
#1

Hi Team, we have made couple of IMP003 PCB’s as it is the best option for a battery powered application. We are facing issues with the Flash memory, IMP is showing LED pattern which is related to Flash Error as per the LED codes mentioned in the datasheet. We are using IS25LP032D-JNLE-TR , we have followed the exact schematic guidelines suggested in the hardware design guide, we have resoldered it again, but the issue persists. Any thoughts?

Only difference i can see is that the flash memory in our layout is a bit far away from the IMP if i compare it with the breakout board, what could be the possible cause?

Request your support.

Regards,
Aman

#2

What flash code is being seen? Is WP# pulled high?

The imp003, at first powerup, will try to write the wifi firmware that’s initially stored within the module out to the SPI flash. If the flash doesn’t work with the default commands (eg is write protected) this will fail and things will not be happy.

Because of this you can’t just swap SPIs after first powerup. If you have done this, then you can recover the device by loading a cloudification image into the SPI - see impOS Downloads | Dev Center

#3

imp003 flash sch
imp003 flash sch1131×633 43.4 KB

I have attached the Flash schematic, the pattern is 500ms red, 250ms amber

#4

I saw the recommended flash memory models in the datasheet, should have used those.

I will try to upload the fw image in the current scenario

#5

I have dim memories of an ISSI part I tested having a different default write protect state than other flash devices, which prevented normal erases/writes from working. That may be the case here too.

#6

We soldered another board to try to find out the problem, we have stm32wb in our board also along with IMP, we initially soldered only the IMP section and tried to blink up, it was done successfully (device connected in the blink up app was shown along with other details) . After that we soldered the stm32wb and somehow again we noticed the long red and amber LED, trying to figure out why this is happening.

#7

Sounds like there may be some sort of circuit issue here. If you DM a circuit diagram I can look and see if there’s anything that might cause that?

#8

Hi Hugo, i have sent you the schematic. We have tested again, as soon as we remove STM32WB from the board IMP starts behaving perfectly, our wild guess is maybe it is because of radio interference

#9

I suspect this is related to your muxing of the imp flash.

You generally cannot do this. The imp will access the flash at unpredictable times (eg if the wifi chip crashes and needs to be re-booted, the imp assumes it can access the flash to pull the wifi firmware from it).

With an unprogrammed STM32WB in theory R20 and R21 will assign the flash just to the imp (and the other lines will be tristate and just capacitively loading the SPI, which shouldn’t be an issue at the default slow speed), but the impedance of U3 could well be a problem here - the flash chip will take large current peaks at certain points, and having ohms in the path isn’t a great idea.

I would probably remove U3 and patch 3v3 directly to the flash (the imp will put flash that can support it in deep power down anyway - eg the Spansion/Cypress parts… though note I would put a 1M pulldown on F_SCLK and F_MISO as we have seen those pins leak even with nCS high). See if that helps, but long term you would need to have a dedicated flash for the STM32WB, or at least proxy flash access through the imp (device talks to imp over UART, imp stores data using hardware.spiflash API).

#10

Hi Hugo, thanks for the support. Everything is good now. The MUX issue was there, found voltage leakage happening there, we shorted the CS line with IMP and it started working perfectly.
Also I wanted to know is IMP003 being discontinued now? because i cannot buy it from mouser or digikey now

#11

It isn’t discontinued, but - as you probably have noticed - pretty much semiconductor stock is hard to get. Lead times are generally a year. You won’t find anything much in stock at mouser or digikey - try buying a TI power supply part, for example!

imp003 is, however, the oldest imp product still available (it was introduced 8 years ago). If you’re making a new design, you really should be picking the imp006 as the most recently introduced imp :slight_smile:

#12

Our procurement team checked and informed us that Type 1CD and MD will be discontinued by Murata by 31.03.23 as per their notice to the distributors dated 17th Feb, 2022. we have already spent a lot on the imp003 development, we will stick to it for now and discuss how to proceed ahead. We may have to design again with imp006 if imp003 will not be available in the market i guess. The reason why we chose imp003 was because of its form factor and low sleep current, form factor specially is very important for our application
Will we have to buy imp006 (stm32f) from imp store?

#13

Interesting, @DillonImp ?

Sleep currents are lower on the imp006 than 003. Size is going to be larger, though.

STM32F423ZHJ6I (note the trailing I) is now listed in distributors, and is the imp006 chip (STM32F423ZHJ6 but with the imp secure bootloader in it). This will be a stocked part in Mouser, Digikey, etc when… well, when semiconductors become available again.

#14

Murata have announced an EOL of the imp003, 1CD, module. Per the announcement they are accepting new orders until March 31st 2023.

The STM32 for the imp006 is available from the Electric Imp store at the below link.

You will also need to pair it with a SPI flash memory with an encrypted and signed impOS image. You can download the image from our website and program a flash
https://developer.electricimp.com/design/impos-downloads
or you can buy the flash pre-programmed from the on-line store

You will need to source Murata 1DX or 1MW WiFi radios via Murata’s franchised distributors

#15

Also note that STM32F423ZHJ6I (with the “-I”) and STM32F423ZHJ6 are functionally equivalent but are not interchangeable at manufacture time – they need different SPI flash images (because the code-signing keys are different). Once correctly manufactured (and “impified”) they are equivalent from then on.

#16

This topic was automatically closed after 60 days. New replies are no longer allowed.