Open dresco opened 1 day ago
This is likely due to the 8-bit CRC used for validating settings beeing inadequate, I should switch to a 16-bit CRC... Adding sanity check to the baud rate may also help (I have not tested this yet though):
static void modbus_settings_load (void)
{
if(hal.nvs.memcpy_from_nvs((uint8_t *)&modbus, nvs_address, sizeof(modbus_settings_t), true) != NVS_TransferResult_OK ||
modbus.baud_rate != baud[get_baudrate(modbus.baud_rate)])
modbus_settings_restore();
is_up = true;
silence_timeout = silence.timeout[get_baudrate(modbus.baud_rate)];
stream.set_baud_rate(modbus.baud_rate);
}
Thanks, I'll leave it if it's on your radar already.
Just wanted to flag it, as has caught me out a couple of times..
Have run into this a few times with the H7 build, and not sure where the problem lies.
Scenario: I have a working grblHAL board, configured without a modbus spindle, and then rebuild & flash with modbus support.
The board will then appear to hang on startup. Looking deeper, the modbus baud rate is being set to 0 from modbus_settings_load(), and the hang is occurring on the first modbus send.
If I then erase the settings storage (using stlink - as using eeprom emulation), the modbus settings are restored as expected, and initialised at 19,200 baud. I've dumped the 'bad' settings memory off the board in case that's helpful..