Closed StefanoSperetta closed 4 years ago
The issue s caused by the fact that the threeByteAddress flag is not set. This can be fixed by changing the MB85RS constructor to:
MB85RS::MB85RS( DSPI &spi, unsigned long csPort, unsigned long csPin, Device dev):
line(spi), CSPort(csPort), CSPin(csPin), device(dev)
{
switch(device)
{
case MB85RS1MT:
threeByteAddress = true;
break;
default:
threeByteAddress = false;
break;
}
}
(wrt the version committed (https://github.com/DelfiSpace/MB85RS/commit/476ee5812b7256cb82e37ffbd305cbb5a80425c0).
But, anyway, there cannot be any failure in the bootloader (for whatever reason) so we need to first fix the bootloader problem (caused by the JumpToSlot function) to make sure we jump back to the 0 location. Afterward, we can commit the fix to the FRAM.
Fixed in https://github.com/DelfiSpace/DelfiPQcore/commit/d16496222d75a9102d6897ff6a149b5987d993b9
When the target slot is undefined, try to set it back to zero and continue the boot instead of calling a reboot.
On one EPS (we kept it nicely for you), there is a permanent failure on the Bootloader.
The EPS boots but the FRAM contains an invalid value and this causes an infinite loop with the console output being:
The error is permanent and the board never boots properly. The FRAM might have have been damaged during initial debugging (the chip was soldered 180deg rotated). You you'd use the committed EPS_Software code on the branch MPPTon4111. Using the committed code (and already programmed it on the board, triggers the fault. Changing the FRAM type on main.cpp on line 43
MB85RS fram(spi, GPIO_PORT_P1, GPIO_PIN0, MB85RS::MB85RS1MT );
to another device makes sure the FRAM is seen as non-present (like MB85RS256A) and the bug is not excited.
The system should flag the error (maybe in an internal variable) but it should land by default to slot 0.