Configuring power control pin for external flash (MX25R64)

[Erlend Isachsen]

Hi.

Problem description

I'm currently using the MX25R64 as an external flash to perform FOTA over SPI on a custom board employing the nRF9160, which is working very well for the most part. However, I have some issues correctly configuring the power control to the flash chip in the dts-files. The external flash is placed within a power domain controlled by a GPIO, and the domain is turned on whenever the control pin is low. There are also other devices than the flash both within this power domain and on the SPI bus. Because I'm using the flash for FOTA, the power needs to be on before the application launches so MCUBoot can find the secondary image. Additionally, the SPI-driver can't have full control of the power domain since it's shared by other devices.

Current implementation and attempts

I'm currently achieving this by configuring the power control pin as a chip-select pin that is configured 'GPIO_ACTIVE_HIGH' (opposite of its real behavior), which makes the SPI-driver set the pin low when I'm using the flash. I have attached my current board files employing this method. This method works, strictly speaking, but it is a quick and dirty fix that breaks code coherency down the line. For instance, everyone working with the board have to remember that this particular power domain has reverse polarity. Also, reconfiguring the GPIO with 'gpio_pin_configure' after boot seems to break the SPI/flash driver, and regardless, it's confusing to have two different pin configurations in the project. Ideally, the pin should be configured correctly in the .dts files. I have tried to do this by specifying the correct pin configuration in 'supply-gpios' for the MX25R64 entry in the dts file (jedec,spi-nor). However, the bootloader could not read the flash id when I did this, and this solution has the other problem that: "The supply state is entirely the responsibility of the device driver" when adding a supply gpio.

Solution?

What would be the correct way to approach this problem? A solution that would work for me is to configure the pin as its own entry in the .dts files, initialize it at a low level, and take manual control of it after boot. However, in that case it's important that I can rely 100% on the pin to be low at boot or the device can potentially be stuck in a boot-loop before the application is even launched.

22_1011_AA_board.zip

[dejans]

Hi, 

I'll look into it tomorrow. 

Best regards,
Dejan

[dejans]

Hi,

You don't need to add your GPIO 2 pin to the SPI configuration in your dts file. You could consider using GPIO 2 pin for controlling power of external flash directly from nRF91. Additionally, connecting GPIO pin with pull-up resistor to VDD would allow you to have your flash power ON until you switch it to OFF in your application.

Best regards,
Dejan

[Erlend Isachsen]

Thanks for the advice. I moved the power control pin outside the SPI configuration in the "...board_common.dts" file and tried to configure it independently with the 'GPIO_PULL_DOWN' flag set, but I couldn't quite get it to work (Setting the power control pin (2) low turns the power domain/flash ON with this board). When building the application with the edited .dts file, MCUBoot can't communicate with the flash and is stuck in a boot loop. However, I'm not sure if I've set it up correctly. I would really appreciate if you could check if my GPIO on pin 2 is configured correctly. I also attached parts of the error log when trying to boot.

22_1011_AA_board_edit_and_log.zip

[dejans]

Hi,

Have you tried removing GPIO_PULL_DOWN from your GPIO configuration?

Best regards,
Dejan

[Erlend Isachsen]

Hi.

Apologies for the delay on this matter. I tried removing GPIO_PULL_DOWN as well as removing the power control pin 2 entriely from the .dts configuration, but both run into the same problem: "Device id ff ff ff does not match config c2 28 17" when trying to read from the external flash. Due to the HW design of the board I can't rely on the pin passively floating low, so I need the nRF9160 to actively pull the pin down before MCUBoot attempts to read the external flash.

[dejans]

Hi,

There are 2 options that you could consider. 
First option is to write your custom code for accessing GPIO and set it as pre_kernel. In other words, you could modify or add device driver and initialize it as pre_kernel. You can read more in Zephyr device driver model. 
The second option is to change/edit MCUboot code manually in order to set the pin at the start. You could do this by adding the function at the beginning of main.c in MCUboot. You could later unset the pin when MCUboot is done and if this is needed.
Out of these 2 options, the second one would be recommended.

Best regards,
Dejan

[Erlend Isachsen]

Thanks.

I will look into the second option. When editing MCUBoot's code, do you know if this is possible to do this without changing MCUBoot's 'main.c' in the SDK? What I'm thinking of specifically is something along the lines of how Simon configures MCUboot as a child image in this sample: nRF9160: HTTP application update using the nRF9160DK's external flash.

[dejans]

Hi,

You would need to create a device driver with a Kconfig which would enable the driver in Zephyr. Then, you could use mcuboot.conf in a child image configuration. This would require some changes in CMakeLists and Kconfig. These changes could be added to the bottom of these files making them maintainable. There are some online resources for which I hope that they could be useful for you and which you might want to look at - first blog, second blog and Zephyr documentation. 

Best regards,
Dejan