trying to read the firmware of a cc2541 0x41.. would return all bytes as 0xFF

Question

trying to read the firmware of a cc2541 0x41.. would return all bytes as 0xFF

Opened this issue 8 years ago · 8 comments

cc_info seems to return ok'ish data (but for the license, bt address and HW version)
Here is the output of ble_info.py What could possibly be going on? (I am asking because I presume it might be somethihg obvious I am not seeing)

INFO: Found a CC2540/41 chip on /dev/ttyUSB0

Chip information:
      Chip ID : 0x4113
   Flash size : 128 Kb
    Page size : 2 Kb
    SRAM size : 8 Kb
          USB : No

Device information:
 IEEE Address : {some hex number}
           PC : 0000

Firmware information:
      License : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
   BT Address : ff:ff:ff:ff:ff:ff
 Hardware Ver : ff

Debug status:
 [ ] CHIP_ERASE_BUSY
 [ ] PCON_IDLE
 [X] CPU_HALTED
 [ ] PM_ACTIVE
 [ ] HALT_STATUS
 [ ] DEBUG_LOCKED
 [X] OSCILLATOR_STABLE
 [ ] STACK_OVERFLOW

Debug config:
 [ ] SOFT_POWER_MODE
 [ ] TIMERS_OFF
 [X] DMA_PAUSE
 [X] TIMER_SUSPEND

Answer 1 · 2016-10-06T08:48:57.000Z

Hello @aguaviva,
I think that's a left-over from my tests with the BLE112/BLE113 modules. If you are not using this library with these modules, you are good to go, because the memory region containing this information should be empty (0xff).

Answer 2 · 2016-10-06T09:36:08.000Z

Excellent, please let me know how can I help. If you have any ideas/links I'll be happy to investigate myself too.

Thanks for the excellent lib!! :)

Answer 3 · 2016-10-17T20:33:23.000Z

Hi again, do you have any pointers/resources I could look into for fixing this bug myself? (Unless you were planning on looking into it yourself anytime soon)

Answer 4 · 2016-10-31T15:15:52.000Z

Hello @aguaviva , I think I am wrong on my statement above. I forgot that I actually moved the license code to ble_info.py. Keep in mind that the ble_xxx.py utilities are useful only for the BlueGiga BLEXXX modules that are also using the CC2540 chip. Otherwise, the output looks reasonable.

Shall I assume that you tried the cc_read_flash.py and it's output is also everything 0xff ?

Answer 5 · 2016-11-01T17:00:45.000Z

Hi Ioanis,

Yes I tried cc_read_flash.py and that returned all 0xff's as well.

I saw you removed the bug label, is this not a bug?

Answer 6 · 2016-11-01T22:33:49.000Z

Hello @aguaviva , I thought the bug was about the extraneous "Firmware information" message. If they were present in the cc_info.py, this was a bug. (This actually was a case in the previous version -- I forgot that I actually separated that part in the ble_info.py).

Regarding the 0xff that doesn't sound like a library issue. This can be caused by a few things:

Your flash is erased and ready to be programmed
Wrong voltage divider resistors (or wiring) in the DD pin, causing it to be permanently on HIGH state.
Damaged chip.

If you are not just trying to download a firmware, you can try a flash/read cycle in order to confirm that it works as expected.

Answer 7 · 2016-12-24T12:37:29.000Z

Hey @aguaviva , what's the status with this issue? Did you manage to address your problem, or it was still getting 0xff every time? Otherwise I will close this issue.

Answer 8 · 2016-12-24T12:43:54.000Z

Hi Ioannis! thanks for following up!

The python script seems to successfully detect the chip ID and the chip status, so it doesnt seem to be any of the 3 issues you mentioned. I still need to try a flash/read cycle, although I'd really like to download the firmware though.