Bad micro blaze behaviour during power off

snipped-for-privacy@gemidis.be pisze:

You can provide ( in fpga ) mux on spi lines with lock which can be only one locked or something like that.

Is it same flash with configuration ?

Adam

Górski Adam pisze:

You can also use very slow clock on spi bus. In this case write cycle will be longer than power down cycle

Adam

Perhaps you could modify the SPI interface along the lines of typical watchdog or EEPROM access registers in microcontrollers. They require a very specific sequence of operations to "unlock" the device (eg to disable the watchdog). Then a random bit of code would be less likely to affect your SPI bus.

--
Ben Jackson AD7GD

http://www.ben.com/

Does the microblaze know that it will be shut down ?

If so, you can erase the whole program memory from the BRAM before shutting down ... Or add some hardware to disconnect the IOB of the SPI once you shutdown ...

But it all pretty much implies you know when you shutdown ...

Sylvain

jeroen,

What I would do is add code to the spi_write subroutine that checks who called it (a list of allowed calling locations is checked before execution), and/or add a check in the spi_write subroutine that a specific memory location or register has been written to in order to allow the operation.

Then before every legitimate call to the spi_write, the special added register has the "go" command written to it, and that command is immediately cleared when recognized by the spi_write subroutine (so it can't happen again without intending it to). The command should be something that is different than any powering down condition, something like 0xAAh, or 0x55h for example.

Austin

Such "write unlock sequences" are intended to prevent a write which could otherwise be caused by a single spurious signal (e.g. as power is lost).

They don't help against spurious code execution (whether at power-down or otherwise), because that's as likely to begin before the "unlock" as after.

Mike

Mike,

The probability that you branch to the spi-write subroutine AFTER the check is possible, I agree.

It is also possible the code branches to a valid section that is going to call the spi_write subroutine.

Hence the reason why I added the check of who calls the spi_write.

Of course, you can jump in right after that check, too.

I think the point is to minimize the probabilities to the point where it meets the requirements of their customers. If there is one, and only one valid address that skips all the checks, then the probabilities are pretty small, and of no concern.

Another suggestion was to slow things down. If the spi_write is called, it waits the power down time before continuing, that helps, too (if it is a real power down, power is down before you do anything bad). You may also call the routine just after the wait, but again, it is the statistics,

Austin

Using a mux on the spi bus does not solve the problem. Since the select signal of this mux is driven by the software, the select mux command will also be called when the uB pointer jumps to the spi_write_subroutine. I had tried that before.

Now I will try the solution which checks who called the spi_write_subroutine.

Many thanks for your reations!

are you absolutely certain this is what is happening? that is, have you tried wiring in a power monitor to reset microblaze and the problem goes away?

it seems unlikely to me. you are saying it randomly jumps and then runs correctly for a bit. all the other registers are randomly changing and the code still works?

but if you are sure this is what is happening...

how about writing some hardware that holds microblaze reset if it tries to access an invalid address. in a 32bit address space, a jump to a random location is likely to be invalid.

alan nishioka snipped-for-privacy@nishioka.com

I am not absolutly certain because I can not look inside the uB during Shut down. But it explains what I tried this far:

1) I have made the spi pins of the fpga tri-state. Only if the uB puts 0xBABE in a 16bit register the spi pins leave the high impedant state and normal spi communication between flash and fpga is possible. ->

spi commands are logged during power down.

2) I removed the opb_spi core from the design. -> only spi bootloader has access to the flash -> no spi commands are logged during power down. 3) opb_spi core enabled and disabled spi subroutines in the uB code. - 4) Driving the uB reset to ground before shutting down the power of the bord (initial design -> opb_core and spi_subroutines enabled) ->

no spi commands are logged during power down.

I think I need some explenation with the following sentence "all the other registers are randomly changing" which registers do you mean?

Seems a nice solution to me but can you explain it more in detail please? How can I trigger my hardware on a jump to an invalid location of the microblaze pointer?

thanks!