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

[aguaviva]

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

[wavesoft]

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).

[aguaviva]

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!! :)

[aguaviva]

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)

[wavesoft]

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 ?

[aguaviva]

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?

[wavesoft]

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.

[wavesoft]

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.

[aguaviva]

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.