LAUNCHXL-CC1352P: cc1352

Part Number: LAUNCHXL-CC1352P

Tool/software:

I' m using a CC1352 processor running a code based on the "sensor" example where I have to acquire a peripheral on the i²c. The acquisition task runs under i2ctransaction in CALLBACK mode and it is triggered by a timer with a period of 100ms. After 4 cycles of the main task (named "sensor_process") the acquisition task continues to run but the sensor_process stalls and the processor can be halted in a procedure called PRCMDeepSleep: after this it is impossible to go further. Can anyone help me please?

  • Hello luigi Desiderato,

    I hope you are doing well. Looking at the PRCMDeepSleep function it relates to the device entering into a lower power mode (sleep), and from what you describe it never wakes up. First, I wanted to ask how modified is your Sensor controller project, what SDK did you develop on, CCS version, and are you using a custom board or LaunchPad?

    Thanks,
    Alex F

  • Hi Alex, answers:
    1) I designed an acquisition scheme running at low level as follows: after a timer interrupt (tick = 100ms), initialized in the first task initialization, its callback is coded with only an I2C_transfer. This transaction operates on an handle obtained opening the i²c with callback mode (and 400kHz data rate) and an I2C_transfer structure both upon task initialization (no errors on i2c transaction ever!). So when the i2c transaction is terminated, a callback from the driver allows me to get the read data and put them into a circular buffer and then posting a semaphore S1. This model runs with the highest priority since it is interrupt driven, but the time used to complete it (and subtracted to the RTOS and the running tasks) is very small, max few tens of microseconds every 100ms. At the task level, I modified the original readSensors with a procedure where the aforementioned semaphore S1 is tested and if it is blocked that function simply exits and no subsequent data can be transmitted on the radio, since the room available for that data in the output buffer simply does not exist (because the relative bit in sensor.frameControl is off) and the transmission of processSensorMsgEvt behaves only for what available by sensor.frameControl bits. When semaphore S1 is turned on, this means some data has been acquired by the underlying mechanism just said and in this case it is simply loaded in the output buffer of processSensorMsgEvt to be sent over the air. The transmission performed by sendSensorMessage always terminates correctly and the data is really received by another equipment over the air after rising the relative bit in sensor.frameControl (which in turn is lowered just after the data has been processed). All seems to be functional, but after ~4 cycles, the sensorProcess stalls on a semaphore appSemHandle in ApiMac_processIncoming. This last function is called is Sensor_process only when sensor.frameControl has no longer other activities to complete but its 1st statement is a "sem_wait ( &appSemHandle )" which stalls the process. I also inserted a watchdog to check if the code has some problem and always the stall happens inside ApiMac_processIncoming. Semaphores appSemHandle is freed also when an user interface event is caused by the CUI keyboard capture mechanism, (and really I don' t' know why this is handled inside an ApiMac functionality) but if you do not operate on the keyboard, the stall arises and I don' t know why, since what I changed from the original code is exactly what I mentioned here. Please note the acquisition mechanism is obviously still running even if the process stalls (and it should be since it is interrupt driven!) but when the circular buffer is full, non further data can be stored in and subsequent acquisition are definitely lost. Circular buffer is over dimensioned and there are no issues there. Instead, running the original sensor code no stall happens.
    2) the SDK is simplelink_cc13xx_cc26xx_sdk_7_41_00_17
    3) CCS version is 12.4.0.00007
    4) I' m using a custom board, but the same problem arises on the LaunchPad since the I/O used are exactly the same for both boards and the i²c lines are coming from free expansion I/O on the Launchpad too.
    Actually I' m trying to trace what happens inside ApiMac_processIncoming (and it is really tedious) to detect if there is an hidden condition to allow a stall, but this is causing a huge time loss, delaying the completion of the work.
    If you have some ideas... thanks in advance.
    Sincerely Luigi

  • Hello Luigi,

    Thank you for your detailed response! 

    Have you already tried separating the I2C task? By that I mean trying to place the I2C task in an unrelated project (let's say an empty project) and running the task there to see if we have any issues. This could tell us that the I2C task is not the issue and could be something in the Sensor project we would need to look into further. 

    Thanks,
    Alex