• State Resolved
  • Locked Locked
  • Replies 4 replies
  • Subscribers 51 subscribers
  • Views 272 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

CC2640R2F-Q1: Distinguish between CC2640R2F-Q1 and CC2642R-Q1 device by Software

ROGERG
Mastermind 34670 points
Part Number: CC2640R2F-Q1
Other Parts Discussed in Thread: CC2640, CC2642R-Q1, , CC2642R, CC2640R2F

Dear Experts, 

could You please let me know, what the best way is to distinguish between CC2640R2F-Q1 and CC2642R-Q1 devices. Basically we would have CC2640 and CC2642 based HW and would like to distinguish those in SW. 

I checked the TRM and there are different instances of information, which could be potentially the right approach, but it is not 100% clear from the register definitions. 

As far as I can see following registers could be used

1) SHDW_DIE_ID_0, SHDW_DIE_ID_1, SHDW_DIE_ID_2, SHDW_DIE_ID_3 --> could not find interpretation of those registers

2) USER_ID & FCFG1:ICEPICK_DEVICE_ID --> Is it possible to unambiguously distinguish between CC2640R2F and CC2642R devices using those registers and how?

Thanks and best regards,

Gregor

  • 0
    TI__Guru* 94028 points

    Hi,

    As the SW for CC2640R2F-Q1 and CC2642R-Q1 are not binary compatible*, do you really need to rely on some register-reads to assess if you are running on one or the other device? I think it would be easier to keep this information somewhere in the code.

    * By "not binary compatible" I mean, you cannot run the exact same HEX file on CC2640R2F-Q1 and CC2642R-Q1 (one device is built around a Cortex M3, while the other is built around a Cortex M4F). This means you will require to build two different HEX files (with different compilation options).

    Let me know if I have missed something,

    Kind regards,

  • 0 in reply to Clément
    TI__Mastermind 34670 points

    Hi Clement,

    plan is to use a bootloader to flash both CC2640 and CC2642 based HW. Depending on the device variant one or the other HEX file will be flashed. 

    In order for this to work we need a way to distinguish between CC2640 and CC2642 variants in SW.

    For example the Bootloader command "COMMAND_GET_CHIP_ID" - can this be used for this purpose and how would You determine, whether it is CC2640 or CC2642?

    Thanks and best regards,

    Gregor

  • 0 in reply to ROGERG
    TI__Guru* 94028 points

    Hi Gregor,

    Thank you for your patience. When you send the command "COMMAND_GET_CHIP_ID", the device answers with the content of the register AON_PMCTL JTAGUSERCODE. The Boot FW is responsible to copy the USER_ID Register to the AON_PMCTL JTAGUSERCODE.

    In other words, the command "COMMAND_GET_CHIP_ID" sends back the content of the USER_ID Register. So, yes, based on the device's answer, you can determine whether it is CC2640R2F-Q1 or CC2642R-Q1.

    The difference will be seen in the PG Revision field ([31:28]), it should be 0b1011 for CC2640R2F-Q1 and 0b0011 CC2642R-Q1.

    FYI, here will be the result of the command "COMMAND_GET_CHIP_ID" for the two devices:

    PG Rev	Version	Reserved	                   Sequence	       PKG	Protocol	Reserved
[31:28]	[27:26]	[25:23]	                           [22:19]	        [18:16]	[15:12]	        [11:0]
0b1011	0b00	0b000	                           0b0000	        0b101	0b1001	        0x000        CC2640R2F-Q1

PG Rev	Version	PA	Reserved   CC13   Sequence	        PKG	Protocol	Reserved
[31:28]	[27:26]	[25]	 [24]	     [23]	   [22:19]	        [18:16]	[15:12]	        [11:0]
0b0011	0b00	0b0  0b0	     0b0	   0b0000	        0b101	0b1001	        0x000        CC2642R-Q1

    More details for other devices and how to interpret the answer of the device to the command "COMMAND_GET_CHIP_ID" can be found in the TRM of the device.

    I hope this will help,

    Kind regards,

  • 0 in reply to Clément
    TI__Mastermind 34670 points

    Hi Clement, 

    thank You very much! This perfectly matches with what we are seeing when testing with "COMMAND_GET_CHIP_ID".

    Many thanks and best regards,

    Gregor