CC2640R2F: Right way of doing simple_peripheral_spin() in the product

Samson Chen1

Intellectual 760 points

Part Number: CC2640R2F

This is maybe a very trial question...

What is the right way of doing simple_peripheral_spin() if the code is used in the product?

In the example code:

static void simple_peripheral_spin(void) { volatile uint8_t x = 0; while(1) { x++; } }

I believe that was for the debugging purpose. For a released product, what is the right way?

Removed the ASSERT away?

Put a reboot code?

Samson

over 6 years ago

0 J Lindh over 6 years ago

TI__Guru 57865 points

Hi Samson,
I am not sure I understand the question. What are you trying to achieve?

0 Samson Chen1 over 6 years ago in reply to J Lindh

Intellectual 760 points

Hello J,

If I am using similar ASSERT code to build the product, I don't want the product hanging on the while(1) { x++; } when there is something wrong.

What I don't know is... For the product to be released to the users, should I make simple_peripheral_spin() no-infinite loop (pretty much ignore those errors), or should I place a reboot code in simple_peripheral_spin() (whatever ASSERT error will trigger a reboot.)

Samson

0 Aslak N. over 6 years ago in reply to Samson Chen1

TI__Mastermind 23440 points

Hi Samson,

I would recommend that you handle each error in whichever way is appropriate to your product. Usually ASSERT is disabled for production I believe.

Mostly it appears the APIs that have an assert are ones that would work always if they work once. It's mostly in the init code, and some checking of whether the connHandle is in the application's list of connections.

Best regards,
Aslak

0 Samson Chen1 over 6 years ago in reply to Aslak N.

Intellectual 760 points

Hello Aslak,

Thank you for the answer.

Samson

Bluetooth®︎

Bluetooth forum

CC2640R2F: Right way of doing simple_peripheral_spin() in the product