The problem seams to stem from the fact that the SST26 doesn’t expect a dummy byte on certain read operations.
So we had to add some logic to prevent the dummy byte from being sent for certain commands.
We also had to disable the region detection feature, since it wasn’t detecting the first region and would just prevent erase operations there.
We updated the _spi_send_read_command function as follows
spif_bd_error CustomSPIFBlockDevice::_spi_send_read_command(int read_inst, uint8_t *buffer, bd_addr_t addr, bd_size_t size)
{
uint32_t dummy_bytes = _dummy_and_mode_cycles / 8;
int dummy_byte = 0;
if(read_inst == 0x03){
dummy_bytes = 0;
}
_spi.select();
// Write 1 byte Instruction
_spi.write(read_inst);
// Write Address (can be either 3 or 4 bytes long)
for (int address_shift = ((_address_size - 1) * 8); address_shift >= 0; address_shift -= 8) {
_spi.write((addr >> address_shift) & 0xFF);
}
// Write Dummy Cycles Bytes
for (uint32_t i = 0; i < dummy_bytes; i++) {
_spi.write(dummy_byte);
}
// Read Data
for (bd_size_t i = 0; i < size; i++) {
buffer[i] = _spi.write(0);
}
_spi.deselect();
return SPIF_BD_ERROR_OK;
}
And then we also had to manipulate the sfdp_find_addr_region to allow writes in the 0 region, even though it wasn’t found by the driver.
I’d love to generalize this into mbed, but I don’t know enough about the rest of the supported chips to say why the behavior of this is unique.