Don't restrict to erasing the first 2 MB of a "2 MB" SIMM

The problem is that over time, the meaning of curChipType has changed.
It was originally meant to exactly map to chips (four SST39SF040 chips
or four M29F160FB5AN6E2 chips) but over time its meaning has shifted to
simply indicating whether the unlock address needs to be shifted or not.

When curChipType is ParallelFlash_SST39SF040_x4, sometimes the
programming size is 4 MB or 8 MB. So don't restrict it to 2 MB.

Note that the erase sector sizes are just plain wrong in this case. In
the future I should read the chip ID and keep a table of sector sizes
for each known chip ID.
This commit is contained in:
Doug Brown 2023-08-02 21:01:30 -07:00
parent 8f3c74a14e
commit a113d4da0d
1 changed files with 3 additions and 3 deletions

View File

@ -536,9 +536,9 @@ static void SIMMProgrammer_HandleErasePortionReadPosLengthByte(uint8_t byte)
// Ensure they are within the limits of the chip size too
if (chipType == ParallelFlash_SST39SF040_x4)
{
if (boundary <= (2 * 1024UL * 1024UL))
if (boundary <= (8 * 1024UL * 1024UL))
{
// OK! We're erasing certain sectors of a 2 MB SIMM.
// OK! We're erasing certain sectors of a SIMM.
USBCDC_SendByte(ProgrammerErasePortionOK);
// Send the response immediately, it could take a while.
USBCDC_Flush();
@ -553,7 +553,7 @@ static void SIMMProgrammer_HandleErasePortionReadPosLengthByte(uint8_t byte)
{
if (boundary <= (8 * 1024UL * 1024UL))
{
// OK! We're erasing certain sectors of an 8 MB SIMM.
// OK! We're erasing certain sectors of a SIMM.
USBCDC_SendByte(ProgrammerErasePortionOK);
// Send the response immediately, it could take a while.
USBCDC_Flush();