Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[rascalito]

Hello!

I'm trying to use the external flash, and I have one problem:
When erasing the flash, I know by experience that it can take time.
On a 256MB flash, it may take about one minute. The one I use right now is
a 4MB, so I have made a workaround by setting a delay long enough.

Is there a way to check the flash status to be sure that it's actually erased,
and that it doesn't depend on the size?

I checked the status, but there are only 4 of them, FLASH_STATUS_INIT or
DETACH or BASIC or FULL.

As soon as I send the command for erase, the status is FLASH_STATUS_BASIC,
and I suppose it doesn't even change.

Is there another register to check for the flash status?

Thanks,

[BRT Community]

Hello,

Unfortunately there are not any other registers which can be utilised to check if the flash has been erased, although your can be certain that if you flash was in the FULL state before issuing the erase command and returns to the BASIC state then the flash has been erased.

I would suggest checking that the CMD_READ and CMD_WRITE pointers are equal after issuing the erase command, at this point you can be certain that the command has executed, something like the following could be used:

Code: [Select]

uint8_t HAL_WaitCmdFifoEmpty(void)
{
uint32_t readCmdPointer;

// Wait until the two registers match
do
{
// Read the graphics processor read/write pointers
readCmdPointer = HAL_MemRead32(EVE_REG_CMD_READ);
                writeCmdPointer = HAL_MemRead32(EVE_REG_CMD_WRITE);

} while ((writeCmdPointer != readCmdPointer) && (readCmdPointer != 0xFFF));


if(readCmdPointer == 0xFFF)
{
// Return 0xFF if an error occurred
return 0xFF;
}
else
{
// Return 0 if pointers became equal successfully
return 0;
}
}
Best Regards,
BRT Community

[rascalito]

Hello!

Thanks for your reply.
I noticed from the documentation that 2 conditions have to be met to read directly bitmaps from flash.
1. The bitmap has to be one of the ASTC modes
2. The flash has to be set to fast mode.

Beside this, fast mode would allow me to check if it's erased (if it's back to basic, then it's erased).
So I tried to set fast mode. But without success. Here is what happens:
- Read the flash status gives me 2
- Write the command CMD_FASTFLASH returns 0, therefore I suppose it's fine. No E1_** code
- Read the flash status returns 2 (BASIC), not 3 (FAST).

Here are the scope captures.
1. For read status (that's basically a rd32 function that works everywhere else)

Code: [Select]

MOSI MISO //
30 25 F0 00 00 4A 43 42 // Flash status register (3025F0)+ extra byte, reply from MISO
00 00 00 00 02 00 00 00 // Send dummy data, get status

2. As for CMD_FLASHFAST, the documentation is a bit ambiguous.
It says: command layout

Code: [Select]

CMD_FLASHFAST // Offset = 0
result // +4
But as far as I understand SPI, the result cannot be part of the command (MOSI), it can just come from the
MISO. So I think it should be (on MOSI)

Code: [Select]

MOSI MISO
CMD_FLASHFAST dummy // Offset = 0
dummy result // +4

Similarily, the C interface should not be void cmd_flashfast(uint32 result);
but rather void cmd_flashfast(uint32 &result); or uint32 cmd_flashfast(void);

However it doesn't work, so I may be wrong.
Here is my CMD_FLASHFAST scope recording:

Code: [Select]

MOSI MISO
B0 25 78 00 4A 43 // Command register
4A FF FF FF 42 00 00 00 // CMD_FLASHFAST
00 00 00 00 00 00 00 00 // Dummy bytes on MOSI, reply on MISO

Is there anything wrong in this sequence?

Thanks,

[BRT Community]

Hello,

Thank you for the update, I do not see any issue sin how you have sequenced your commands.
However please note that the .blob file must be written to the flash IC for you to be able to place it in FAST mode, I've replied on your other post on how to upload the flash .blob file if you are not using a flash image built from EAB which incorporates this.

Best Regards,
BRT Community

[darkjezter]

Just to add, in cases where coprocessor commands return a result, that result is actually placed in the command FIFO at the location labeled 'result' in your example.

So, in order for your C function to retrieve the result returned by the coprocessor, you need to:

• track where in the command FIFO the result is placed when you send the command
• wait for the coprocessor to finish executing that command
• perform a read operation on the location determined above
• return the result of that read operation through your C function argument pointer

Perhaps you already know this, and/or the library is taking care of this for you, but you'll want to keep it in mind if you're looking at scope traces of the SPI traffic.