Bug limiting CANMap

[Modellfan]

I get very reproducible limit of mapping transmit messages on SDU and Zombieverter at arround 20 signals. Much below 50 Signals and 10 Messages limit.

From webinterface I can narrow it down to:
CAN mapping SDO abort at subindex 2 (gain and offset): 0x06020000

I used the same signal to make sure, that it is not the signal definition itself to stop it. Also with completely different signal same symptoms.

I guess, it is either about timing that the handshake is interrupted after a certain time by other SDO messages or by a bug not corretly using the CanMap in int CanMap::Add(CANIDMAP *canMap, Param::PARAM_NUM param, uint32_t canId, uint8_t offsetBits, int8_t length, float gain, int8_t offset)

I am missing knowledge, how to debug the Zombieverter during runtime, to narrow down the error cause.

[jsphuebner]

I tested this with the most recent Zombie version and I pushed past 20 messages.

[Modellfan]

Is there a way, that I corrupted the stored parameter mapping in flash? I deleted all mappings. communication to Zombie is working. I still can't add any mappings. Now I am back to zero mappings possible. I need to reset my flash, it'S just a feeling for now. Just used the webinterface, so still feels like a bug not missuse.

[jsphuebner]

Can you extract the last 2k of flash from Zombie before doing anything else? Or maybe just dump the entire flash. Which processor are you on?

[jsphuebner]

Our AI friend has also found something. Maybe the flash image was corrupted before and now limits you

[Modellfan]

0x8000000 vcu.bin.txt

Does this work?

[Modellfan]

My guess was right. Erased flash. Reflashed with old libopeninverter. Now can save more than 40 message mappings to flash. All fine.

Okay, I provoked it again. Deleted all 40 and added again 10. Then no more are possible. Seems like I am the first person to test, the deletion of can mappings. Obviously old spaces are not realy freed in flash.

Is there any chance to clear the persistent flash without the programmer? I don't want to disassemble my sdu for it. If not we should let copilote add it as a feature. Other folks will run into it sooner or later as well.

[Modellfan]

Sorry but did you test the code before pushing it? It is not working at all for me. Due to lack of debugging I guess repeated bootloop . I loaded the code on the VCU with updated libopeninv -> not accessible via webinterface. Latest code release of zombievcu loaded -> everything normal. Updated code via can bootloader to new libopeninv -> no reaction.

[jsphuebner]

Trying to remember... no I did not. Will look into it tomorrow

[Modellfan]

I am sorry. Problem is solved was not able to reproduce the problem. Didn't notice on my zombie vcu fork that sdo integration in main.cpp was changed. Now everything is working. Thanks.