G400 uses SPI1 for its internal flash. Fine. But what if I connect another flash chip to SPI (using a separate Chip Select pin). Is it possible that, under whatever circumstances, internal flash access interrupts external flash access? So that my Chip Select pin stays low, while firmware reads/writes internal flash?
Are you asking this as a hypothetical or are you actually having this issue? Connecting any other SPI device to SPI1 should not interfere with the SPI operations of the main system dataflash nor should the main system dataflash interfere with the operation of any other SPI devices on SPI1. As SPI relies on the chip select, both should be independent of each other. The main system dataflash chip select is on the internal chip select of the G400’s main processor for automatic control of the main system dataflash.
May be I am wrong but to avoid that the CS pin should be pulled up. Thus unless the G400 pulls down this pin, external flash can’t be access.
I’m having mysterious issues that drive me crazy, so I’m trying to figure out.
My external flash works entirely on NETMF SPI construct; is it tthe case with internal flash? I don’t know internals of your firmware (and low level NETMF, too), but since SAM9x35 cannot contain code and is automatically started from external flash, I assume internal flash may work on a much lower level. No?
I know, but unless GHI firmware flash access relies entirely on NETMF SPI implementation, there’s probably no guarantees that Chip Selects for both flashes stay synchronised. That is, if firmware needs to access internal flash, it may be possible that external flash’ Chip Select stays active low. This is what I am trying to find out…
This may occurs only if the processor pulls down the IO somewhere else in the startup,update or whatever process in the code. GHI should inform about that. When GHI said that io is open drain, is it open drain for all the process (boot up startup update…)
@ leforban - I guess the question is whether the code is executed from flash, o first loaded into RAM and then executed from there. I need a comment from GHI here. If it runs straight from flash, I may be in trouble…
@ Simon from Vilnius - the code is not executed from flash directly. It is first loaded to external RAM then the code is executed. SAM-BA looks for viable code from the main system flash then loads the program into external RAM and is executed from there.
@ Aron - Ok, it gets better. Does your firmware, once loaded, access flash again without my specific actions? Like, for example, to setting DHCP server settings probably involves reading/writing flash; but what if I don’t touch configuration or EWR? Are there any hidden calls to internal flash?
The firmware should not access the flash again without your specific actions like the config or EWR.
Perhaps you may want to try to see if you are experiencing similar behavioral issues while using SPI 2 with your flash chip so we can try to narrow down the issue?
@ Aron - Ok, pretty clear now, thanks.
I would love to track that issue, but unfortunately it is very [em]random[/em], and it usually happen somewhere in Boston or San Jose… So I can’t really catch it
No Problem. ;D
@ Simon Which flash device are you using?