CC1312R: How to set the CC1312 to 433 frequency?

Hi Edvard,

I have already upgrade SDK to simplelink_cc13x2_sdk_2_20_00_71.
However, after I change CONFIG_PHY_ID to APIMAC_GENERIC_CHINA_433_PHY_128 for collector and upgrade the FW to our module, our module can't boot anymore and can't detect by JTAG again.

So I have the following questions:
1. Are there any circumstances that FW behaviour will cause JTAG can't detect CC1312?
2. From simplelink_cc13x2_sdk_1_60_00_29, there is only one pOverrides in pOverridesTable.
However, from simplelink_cc13x2_sdk_2_20_00_71, there are multiple pOverrides in pOverridesTable in mac_user_config_cc13x2r1_subg_china.h or mac_user_config_cc13x2r1_subg_us_euro.h like below:
const uint32_t *pOverridesTable[] =
{ 0, /* for CC1312R1 433 MHz is unsupported */
0, /* for CC1352R1 433 MHz is unsupported */
(uint32_t *) pOverrides_fsk_433_CC1352P1_DPA, /* for CC1352P1, mac initialization entry */
0, /* for CC1352P1 433 MHz is unsupported */
(uint32_t *) pOverrides_fsk_433_CC1352P1_DPA, /* for CC1352P1 DPA 433 MHz */
(uint32_t *) pOverrides_fsk_433_CC1352P1_HPA }; /* for CC1352P1 HPA 433 MHz */
My question is how the FW determine which table to use?
Can I add my own pOverrides setting and specify the FW to use my own pOverrides?
3. From the above source, it seems that only CC1352P1 supports 433 MHz.
Can I also enable 433 MHz for CC1312R1?
4. From the above source, what's the difference between DPA and HPA?

Thanks!

Best regards,
Vince

hi Vince,
which PG do you use ? You can use Uniflash to check the PG number on your CC1312.

Hi Jerry,

We use PG2.1.

PG 2.1 does not exist for CC1312...

Sorry, I got wrong.

It's only PG1.1.

Vince,

1. Have you tried to do a Forced Mass Erase of the device?
2. I'll consult with an expert on this.
3. The short answer is yes. The slightly less shorter answer is that it's a matter of missing settings.
4. DPA = default PA, HPA = high PA.

Hi Edvard,

1. Because JTAG can't connect to CC1312R anymore, I can't do Forced Mass Erase via Uniflash.

2. Thanks, I will wait for your reply.

3. ok

4. ok

From the above discussion, are there any compatibility issues for simplelink_cc13x2_sdk_2_20_00_71 on PG1.1?

Best regards,

Vince

Hi Edvard,

Is there "Force Erase" function on Uniflash ? We know Flash Programmer 2 have this function. However, Flash Programmer 2 cannot use for CC1312.

On mass erase, see this thread: e2e.ti.com/.../2512822

Hi TI,

I found that smartrf can still get CC1312.

It means JTAG connection still works.

However uniflash can't read/write config and load firmware to CC1312.

It always return Error -2062.

I have the following question:

1. What does error -2062 mean?

2. Do you have any flash lock mechanism in the chip?

    Because smartrf can get but uniflash can't work, I suspect it's flash related problem.

3. Because I can't do Forced Mass Erase, are there any other methods to save the chip back?

Thanks!

Best regards,

Vince

Hi team,
Summarize as below questions which need team's reply.
1. What does Uniflash "error -2062" mean?
2. Is there any flash lock mechanism in the chip?
Because smartrf can get but Uniflash can't work. Customer suspect it's flash related problem.
3. Because we can't do Forced Mass Erase, are there any other methods to save the chip back?
4. From simplelink_cc13x2_sdk_1_60_00_29, there is only one pOverrides in pOverridesTable.
However, from simplelink_cc13x2_sdk_2_20_00_71, there are multiple pOverrides in pOverridesTable in
mac_user_config_cc13x2r1_subg_china.h or mac_user_config_cc13x2r1_subg_us_euro.h like below:
const uint32_t *pOverridesTable[] =
{ 0, /* for CC1312R1 433 MHz is unsupported */
0, /* for CC1352R1 433 MHz is unsupported */
(uint32_t *) pOverrides_fsk_433_CC1352P1_DPA, /* for CC1352P1, mac initialization entry */
0, /* for CC1352P1 433 MHz is unsupported */
(uint32_t *) pOverrides_fsk_433_CC1352P1_DPA, /* for CC1352P1 DPA 433 MHz */
(uint32_t *) pOverrides_fsk_433_CC1352P1_HPA }; /* for CC1352P1 HPA 433 MHz */
==> question is how the FW determine which table to use?
Can customer add their own pOverrides setting and specify the FW to use my own pOverrides?

Thank you.

Hi TI,

Due to collector problem, I try to use coprocessor example to test 433MHz.
However, even I test coprocessor on CC1312 launchpad, there is still a problem that when I send MT command to set PHY-ID to 128 (433MHz), the coprocessor blocked and doesn't respond to any MT command anymore.
The command payload is 0xFE 0x11 0x22 0x09 0xE8 0x80 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x52.

I think it maybe also the problem related to 433MHz support for CC1312.
Do you have any suggestion about this?
Thanks!

Best regards,
Vince

Hi Vince,

I am currently investigating this issue, I will up date you updated on my findings.

Regards,

Hector

Hi TI,

Do you have any update about this problem?

Best regards,
Vince

hi team,

I find 433MHz mode can work on CC1352P1 launchpad. I use "collector_cc1352p1lp" & "sensor_cc1352p1lp" on CC1352P1 launchpad. Both work fine. Please investigate why 433MHz mode cannot work on CC1312R (also not work on CC1352R).
Thank you.

Hi M-W,

Does it mean that simplelink_cc13x2_sdk_2_20_00_71 SDK still can't support 433 MHz PHY on the 15.4 stack for CC1312R?
If yes, when do you plan to support?

Besides, can you answer the following question first?

From simplelink_cc13x2_sdk_1_60_00_29, there is only one pOverrides in pOverridesTable.
However, from simplelink_cc13x2_sdk_2_20_00_71, there are multiple pOverrides in pOverridesTable in
mac_user_config_cc13x2r1_subg_china.h or mac_user_config_cc13x2r1_subg_us_euro.h like below:
const uint32_t *pOverridesTable[] =
{ 0, /* for CC1312R1 433 MHz is unsupported */
0, /* for CC1352R1 433 MHz is unsupported */
(uint32_t *) pOverrides_fsk_433_CC1352P1_DPA, /* for CC1352P1, mac initialization entry */
0, /* for CC1352P1 433 MHz is unsupported */
(uint32_t *) pOverrides_fsk_433_CC1352P1_DPA, /* for CC1352P1 DPA 433 MHz */
(uint32_t *) pOverrides_fsk_433_CC1352P1_HPA }; /* for CC1352P1 HPA 433 MHz */
==> question is how the FW determine which table to use?
Can I add pOverrides setting and specify the FW to use my own pOverrides?

Thanks!

Best regards,
Vince

Hi Vince,

I will have to look into the schedule on the 433 MHz PHY support and get back to you on that.

Regarding the overrides, while you could try to add your own overrides or reuse the DPA overrides for the CC1352P1 board for the CC1312R, I found that this alone is not enough to get the stack to run. I will reach out to the stack developers and see if there is any way of using 433 MHz based on custom overrides today.

Hi Vince,

I have been able to run 433 MHz on the CC1352R1 devices by populating all the missing entries in pOverridesTable and macTxPwrTbl. I re-used the pOverrides_fsk_433_CC1352P1_DPA and txPowerTable_subg_433_CC1352P1_DPA entry to replace all the null entires. After doing this, I was able to run the sensor and collector and form a network.

Hi M-W,

Thanks for your reply.
Our modules can connect to each other by using your method.

Although 433 connection is ok, we still want to understand the following things
1. How the FW determine which entry to use in pOverridesTable and macTxPwrTbl?
From my experimentation, CC1312R uses the fourth entry in pOverridesTable and macTxPwrTbl.
So if we change the fourth entry from null to pOverrides_fsk_433_CC1352P1_DPA and txPowerTable_subg_433_CC1352P1_DPA, it can work.
But why it's the fourth entry, how the FW determine? Can we specify which entry to use?
2. Some of our module have been locked when we use FW with null entries in pOverridesTable and macTxPwrTbl.
Uniflash will return error -2062 when we want to access flash.
What's the reason for this situation? Can we save them back?

Thanks!

Best regards,
Vince

Hi Jerry,

Could you elaborate on "Uniflash cannot enter", do you mean that the device can not be detected and connected to by pressing "start" on the device?

Or can you connect to the device by pressing "Start" just that you can't read out the flash content?

Hi M-W,

please see what Vince posted on Fri, Jul 20 2018 12:31 AM. Uniflash can detect CC1312. However, after click "Start", it will show Error -2062.
I attach the snapshot again.

As I understands it, this error is encountered not when pressing "start" to connect to the target, but when trying to do an "Erase Entire Flash"?

Hi M-W,

The error is not only encountered when do an "Erase Entire Flash".
It's encountered when do all flash related operations, like loading firmware, erasing, reading settings ...etc.

Best regards,
Vince

Hi Vince,

What kind of hardware are you seeing this problem on, is it custom hardware or launchpads?
If it is custom hardware, is the reset pin connected to the debugger? Could share pictures of the hardware you are using and how the debugger is connected?