Hi,
We have many devices operating correctly.
For some reason, at some point in time, the device fails to initialize (no mater how much we reboot or reset it).
When I send this configuration:
NCI >> 20 02 a3 13 a0 0d 06 04 35 90 01 f4 01 a0 0d 06 06 44 01 90 03 00 a0 0d 06 06 30 b0 01 10 00 a0 0d 06 06 42 02 00 ff ff a0 0d 03 06 3f 04 a0 0d 06 20 42 88 00 ff ff a0 0d 04 22 44 22 00 a0 0d 06 22 2d 50 34 0c 00 a0 0d 06 32 42 f8 00 ff ff a0 0d 06 34 2d 24 37 0c 00 a0 0d 06 34 33 86 80 00 70 a0 0d 04 34 44 22 00 a0 0d 06 42 2d 15 45 0d 00 a0 0d 04 46 44 22 00 a0 0d 06 46 2d 05 59 0e 00 a0 0d 06 44 42 88 00 ff ff a0 0d 06 56 2d 05 9f 0c 00 a0 0d 06 54 42 88 00 ff ff a0 0d 06 0a 33 80 86 00 70
I get this response:
NCI << 40 02 08 09 03 a0 0d a0 0d a0 0d
which is causing the problem, as the library expects 40 02 00 00.
I have no idea what does the "08 09" in my case means, and how can fix this?
Is there any tool to interpret those messages? any manual i can look into?
Any hints on this urgent matter would be much appreciated.
Hello,
The issue relates to internal EEPROM memory corruption. This issue is described in UM10936 chapter 10.3, and must be avoided following recommendations depicted there. Unfortunately, there is no way to recover from this issue on the corrupted device.
FYI, in "NCI << 40 02 08 09 03 a0 0d a0 0d a0 0d" frame:
- "40 02" indicates the frame type (response to CORE_SET_CONFIG command)
- "08" indicates the payload size
- "09" is the status byte (STATUS_INVALID_PARAM)
Hope this helps.
BR,
Ivan.
Thank you Ivan.
So, just to confirm: the chips having this issue should simply be discarded?
Hmm... no way to rewrite the EEPROM?
Hello,
Please accept my apologies, since the memory was corrupted, there is no way to recover from this.
BR,
Ivan.