[Contiki-developers] CC2650 Sensortag ADC reading with new cc26xxware

[Andreas Urke]

Hi,
I am having trouble with the newest cc26xxware and reading from the ADC. I
wonder if anyone been successful doing this?

With the previous version of cc26xxware I was able to read values as long
as it was not within an etimer (in that case AUXADCReadFifo() never
returned). However, now I get a hard fault (continuous calls to

AUXADCSelectInput(ADC_COMPB_IN_AUXIO7);

AUXADCEnableSync(AUXADC_REF_FIXED, AUXADC_SAMPLE_TIME_2P7_US,

AUXADC_TRIGGER_MANUAL);

(Previous examples
included AUXWUCClockEnable(AUX_WUC_ADI_CLOCK|AUX_WUC_SOC_CLOCK) but it
seems these clocks are enabled by default in new cc26xxware.)

I have checked the TI ADC examples for the sensor controller and it seems
they are doing these same tasks at init.

Any hints appreciated! I am on bleeding-edge contiki and using sensortag +
debugger 1.2. Link to TI forum post:
https://e2e.ti.com/support/wireless_connectivity/f/158/t/457504
Regards,
Andreas U.

[Andreas Urke]

​​Digging some more I found after calling AUXWUCClockEnable() I continuosly
fall into a special case in the fault_handlers_hard_fault_isr(), see
cpu/cc26xx-cc13xx/fault-handlers.c :

/*
* Workaround for (Im)precise Bus Faults caused under unknown circumstances,
* likely by access to RFC registers while the RF PD is off (which is
* something that should never happen because we do in fact check before
* accessing)
*/
if((HWREG(CPU_SCS_BASE + CPU_SCS_O_CFSR) == CPU_SCS_CFSR_IMPRECISERR) ||
(HWREG(CPU_SCS_BASE + CPU_SCS_O_CFSR) & CPU_SCS_CFSR_PRECISERR)){
/* ToDo: Check BFARVALID and then BFAR to filter down even further */
return;

I also rolled back to the CC26xxware 2.21.01.15600 and a corresponding
Contiki commit bfcea70 and confirmed ADC works. I then updated only
CC26xxware to 2.21.03.15980 (making a few minor changes in Contiki to get
it to compile), and I get the same error. Not sure where to go from here,
anyone got suggestion for further debugging?

Andreas

Post by Andreas Urke
Hi,
I am having trouble with the newest cc26xxware and reading from the ADC. I
wonder if anyone been successful doing this?
With the previous version of cc26xxware I was able to read values as long
as it was not within an etimer (in that case AUXADCReadFifo() never
returned). However, now I get a hard fault (continuous calls to

AUXADCSelectInput(ADC_COMPB_IN_AUXIO7);

AUXADCEnableSync(AUXADC_REF_FIXED, AUXADC_SAMPLE_TIME_2P7_US,

AUXADC_TRIGGER_MANUAL);

(Previous examples
included AUXWUCClockEnable(AUX_WUC_ADI_CLOCK|AUX_WUC_SOC_CLOCK) but it
seems these clocks are enabled by default in new cc26xxware.)
I have checked the TI ADC examples for the sensor controller and it seems
they are doing these same tasks at init.
Any hints appreciated! I am on bleeding-edge contiki and using sensortag +
https://e2e.ti.com/support/wireless_connectivity/f/158/t/457504
Regards,
Andreas U.

[George Oikonomou]

Hi Andreas

Can you debug the fault? Is it precise or imprecise? If it's precise, which address causes it (value of BFAR)?

I suspect something related to low power modes here. Can you prohibit deep sleep and see if it stops happening?

Post by Andreas Urke
/*
* Workaround for (Im)precise Bus Faults caused under unknown circumstances,
* likely by access to RFC registers while the RF PD is off (which is
* something that should never happen because we do in fact check before
* accessing)
*/
if((HWREG(CPU_SCS_BASE + CPU_SCS_O_CFSR) == CPU_SCS_CFSR_IMPRECISERR) ||
(HWREG(CPU_SCS_BASE + CPU_SCS_O_CFSR) & CPU_SCS_CFSR_PRECISERR)){
/* ToDo: Check BFARVALID and then BFAR to filter down even further */
return;
I also rolled back to the CC26xxware 2.21.01.15600 and a corresponding Contiki commit bfcea70 and confirmed ADC works. I then updated only CC26xxware to 2.21.03.15980 (making a few minor changes in Contiki to get it to compile), and I get the same error. Not sure where to go from here, anyone got suggestion for further debugging?
Andreas
Hi,
I am having trouble with the newest cc26xxware and reading from the ADC. I wonder if anyone been successful doing this?
AUXADCSelectInput(ADC_COMPB_IN_AUXIO7);
AUXADCEnableSync(AUXADC_REF_FIXED, AUXADC_SAMPLE_TIME_2P7_US, AUXADC_TRIGGER_MANUAL);
(Previous examples included AUXWUCClockEnable(AUX_WUC_ADI_CLOCK|AUX_WUC_SOC_CLOCK) but it seems these clocks are enabled by default in new cc26xxware.)
I have checked the TI ADC examples for the sensor controller and it seems they are doing these same tasks at init.
Any hints appreciated! I am on bleeding-edge contiki and using sensortag + debugger 1.2. Link to TI forum post: https://e2e.ti.com/support/wireless_connectivity/f/158/t/457504 <https://e2e.ti.com/support/wireless_connectivity/f/158/t/457504>
Regards,
Andreas U.
------------------------------------------------------------------------------
_______________________________________________
Contiki-developers mailing list
https://lists.sourceforge.net/lists/listinfo/contiki-developers

[Andreas Urke]

Hi George,

It is the precise,
Value of HWREG(CPU_SCS_BASE + CPU_SCS_O_CFSR) is 0x8200.

Value of HWREG(CPU_SCS_O_BFAR) is 0xFF22F00D.

All my tests have actually been with LPM_MODE_MAX_SUPPORTED set to
LPM_MODE_SLEEP.

Andreas

Post by George Oikonomou
Hi Andreas
Can you debug the fault? Is it precise or imprecise? If it's precise,
which address causes it (value of BFAR)?
I suspect something related to low power modes here. Can you prohibit deep
sleep and see if it stops happening?
​​Digging some more I found after calling AUXWUCClockEnable() I
continuosly fall into a special case in the
/*
* Workaround for (Im)precise Bus Faults caused under unknown circumstances,
* likely by access to RFC registers while the RF PD is off (which is
* something that should never happen because we do in fact check before
* accessing)
*/
if((HWREG(CPU_SCS_BASE + CPU_SCS_O_CFSR) == CPU_SCS_CFSR_IMPRECISERR) ||
(HWREG(CPU_SCS_BASE + CPU_SCS_O_CFSR) & CPU_SCS_CFSR_PRECISERR)){
/* ToDo: Check BFARVALID and then BFAR to filter down even further */
return;
I also rolled back to the CC26xxware 2.21.01.15600 and a corresponding
Contiki commit bfcea70 and confirmed ADC works. I then updated only
CC26xxware to 2.21.03.15980 (making a few minor changes in Contiki to get
it to compile), and I get the same error. Not sure where to go from here,
anyone got suggestion for further debugging?
Andreas

Post by Andreas Urke
Hi,
I am having trouble with the newest cc26xxware and reading from the ADC.
I wonder if anyone been successful doing this?
With the previous version of cc26xxware I was able to read values as long
as it was not within an etimer (in that case AUXADCReadFifo() never
returned). However, now I get a hard fault (continuous calls to

AUXADCSelectInput(ADC_COMPB_IN_AUXIO7);

AUXADCEnableSync(AUXADC_REF_FIXED, AUXADC_SAMPLE_TIME_2P7_US,

AUXADC_TRIGGER_MANUAL);

(Previous examples
included AUXWUCClockEnable(AUX_WUC_ADI_CLOCK|AUX_WUC_SOC_CLOCK) but it
seems these clocks are enabled by default in new cc26xxware.)
I have checked the TI ADC examples for the sensor controller and it seems
they are doing these same tasks at init.
Any hints appreciated! I am on bleeding-edge contiki and using sensortag
https://e2e.ti.com/support/wireless_connectivity/f/158/t/457504
Regards,
Andreas U.

------------------------------------------------------------------------------
_______________________________________________
Contiki-developers mailing list
https://lists.sourceforge.net/lists/listinfo/contiki-developers
------------------------------------------------------------------------------
_______________________________________________
Contiki-developers mailing list
https://lists.sourceforge.net/lists/listinfo/contiki-developers

[George Oikonomou]

Post by Andreas Urke
Value of HWREG(CPU_SCS_O_BFAR) is 0xFF22F00D.

OK that confuses me. I cannot find that offset in hw_memmap.h Makes me think it's something internal to the AUX. Have you tried explicitly powering up the aux before trying the conversion?

[Andreas Urke]

​Would that be ​PRCM_DOMAIN_PERIPH? (I'm not too familiar at this low
level). ti_lib_prcm_power_domain_status() shows it is powered on.
Nevertheless I tried powering it right before calling AUXWUCClockEnable(),
but problem persist.

Btw, during my tests I now saw the following values in BFAR
FF20 F00D
FF30 F00D

Post by Andreas Urke
Value of HWREG(CPU_SCS_O_BFAR) is 0xFF22F00D.
OK that confuses me. I cannot find that offset in hw_memmap.h Makes me
think it's something internal to the AUX. Have you tried explicitly
powering up the aux before trying the conversion?
------------------------------------------------------------------------------
_______________________________________________
Contiki-developers mailing list
https://lists.sourceforge.net/lists/listinfo/contiki-developers

[Andreas Urke]

You were right George:

I tried calling SysCtrlPowerEverything() before enabling the clock and it
then gave 1 reading (see code bottom) before the precise hard faults come.
Removing PROCESS_PAUSE before every reading gave me ~6 readings. Thinking
aloud, it seemed to be some timing - something being turned off after x
amount of time.

I then added SysCtrlPowerEverything() before every reading as well but this
only gave me about 40 readings before precise hard faulting (FF6C F00D).
Putting the powerEverything()+reading into a 1 sec etimer solved it, and I
am now able to get readings reliably. However, setting etimer to very low
values, e.g two ticks, will cause hard fault again (FF6C F00D).

So from my perspective the open issues are 1) What should should actually
be powered, 2) Understand why it fails at rapid reading. I have not studied
the ADC spec yet, maybe there are some limitations when reading this way.


For ref, my code:

AUXWUCClockEnable(AUX_WUC_ADI_CLOCK|AUX_WUC_ANAIF_CLOCK);
AUXADCSelectInput(ADC_COMPB_IN_AUXIO7);
AUXADCEnableSync(AUXADC_REF_FIXED, AUXADC_SAMPLE_TIME_2P7_US,
AUXADC_TRIGGER_MANUAL);

while(1)
{

PROCESS_PAUSE();

AUXADCGenManualTrigger();

reading = AUXADCReadFifo();

}

Post by Andreas Urke
​Would that be ​PRCM_DOMAIN_PERIPH? (I'm not too familiar at this low
level). ti_lib_prcm_power_domain_status() shows it is powered on.
Nevertheless I tried powering it right before calling AUXWUCClockEnable(),
but problem persist.
Btw, during my tests I now saw the following values in BFAR
FF20 F00D
FF30 F00D

Post by Andreas Urke
Value of HWREG(CPU_SCS_O_BFAR) is 0xFF22F00D.
OK that confuses me. I cannot find that offset in hw_memmap.h Makes me
think it's something internal to the AUX. Have you tried explicitly
powering up the aux before trying the conversion?
------------------------------------------------------------------------------
_______________________________________________
Contiki-developers mailing list
https://lists.sourceforge.net/lists/listinfo/contiki-developers

[George Oikonomou]

Andreas

I tried calling SysCtrlPowerEverything() before enabling the clock and it then gave 1 reading (see code bottom) before the precise hard faults come. Removing PROCESS_PAUSE before every reading gave me ~6 readings.

I think the calls that do it are here: https://github.com/g-oikonomou/cc26xxware/blob/master/driverlib/sys_ctrl.c#L126

AONWUCAuxWakeupEvent(AONWUC_AUX_WAKEUP);
while(!(AONWUCPowerStatusGet() & AONWUC_AUX_POWER_ON))
{ }

and

AUXWUCClockEnable(ui32AuxClocks);
while(AUXWUCClockStatus(ui32AuxClocks) != AUX_WUC_CLOCK_READY)
{ }

Thinking aloud, it seemed to be some timing - something being turned off after x amount of time.

Entering deep sleep (lpm_drop() in main) forces Aux back off.

I then added SysCtrlPowerEverything() before every reading as well but this only gave me about 40 readings before precise hard faulting (FF6C F00D). Putting the powerEverything()+reading into a 1 sec etimer solved it, and I am now able to get readings reliably. However, setting etimer to very low values, e.g two ticks, will cause hard fault again (FF6C F00D).

Pausing between powering up the aux and taking the reading yields control back to main and the chip may go into deep sleep during the pause. This will turn the aux back off.

So from my perspective the open issues are 1) What should should actually be powered,

So my gut feeling is that all you need to do is make sure Aux is powered up and clocked immediately before you trigger a reading.

2) Understand why it fails at rapid reading.

Not sure about that one

AUXWUCClockEnable(AUX_WUC_ADI_CLOCK|AUX_WUC_ANAIF_CLOCK);

I suspect you need the ADC clock too: AUX_WUC_ADC_CLOCK

​Would that be ​PRCM_DOMAIN_PERIPH? (I'm not too familiar at this low level).

It is not the PERIPH PD, the Aux is controlled separately.

George

[Andreas Urke]

Thanks George,
​​
you were right regarding the power, AONWUCAuxWakeupEvent(AONWUC_AUX_WAKEUP)
is the correct one. Regarding the ADC_CLOCK, this is being enabled in
AUXADCEnableSync().

I have disabled deep sleep. Furthermore, if I do 4 samples in each etimer
event it will fail after a few successful events, while it's fine if I do
only 2 samples in each. Am I correct in assuming that as long as my process
has not relinquished control (reached PROCESS_WAIT_EVENT or similiar) it
can not be interrupted by some other contiki-mechanism e.g. making it go to
sleep? If yes, I'm thinking there's something non-contiki stopping the show.

Andreas

Post by Andreas Urke
Andreas
I tried calling SysCtrlPowerEverything() before enabling the clock and it
then gave 1 reading (see code bottom) before the precise hard faults come.
Removing PROCESS_PAUSE before every reading gave me ~6 readings.
https://github.com/g-oikonomou/cc26xxware/blob/master/driverlib/sys_ctrl.c#L126
AONWUCAuxWakeupEvent(AONWUC_AUX_WAKEUP);
while(!(AONWUCPowerStatusGet() & AONWUC_AUX_POWER_ON))
{ }
and
AUXWUCClockEnable(ui32AuxClocks);
while(AUXWUCClockStatus(ui32AuxClocks) != AUX_WUC_CLOCK_READY)
{ }
Thinking aloud, it seemed to be some timing - something being turned off
after x amount of time.
Entering deep sleep (lpm_drop() in main) forces Aux back off.
I then added SysCtrlPowerEverything() before every reading as well but
this only gave me about 40 readings before precise hard faulting (FF6C
F00D). Putting the powerEverything()+reading into a 1 sec etimer solved it,
and I am now able to get readings reliably. However, setting etimer to very
low values, e.g two ticks, will cause hard fault again (FF6C F00D).
Pausing between powering up the aux and taking the reading yields control
back to main and the chip may go into deep sleep during the pause. This
will turn the aux back off.
So from my perspective the open issues are 1) What should should actually be powered,
So my gut feeling is that all you need to do is make sure Aux is powered
up and clocked immediately before you trigger a reading.
2) Understand why it fails at rapid reading.
Not sure about that one
AUXWUCClockEnable(AUX_WUC_ADI_CLOCK|AUX_WUC_ANAIF_CLOCK);
I suspect you need the ADC clock too: AUX_WUC_ADC_CLOCK
​Would that be ​PRCM_DOMAIN_PERIPH? (I'm not too familiar at this low

Post by Andreas Urke
level).

It is not the PERIPH PD, the Aux is controlled separately.
George
------------------------------------------------------------------------------
_______________________________________________
Contiki-developers mailing list
https://lists.sourceforge.net/lists/listinfo/contiki-developers

[George Oikonomou]

Andreas, good news - getting there

You are right, for as long as your process is running, the chip won't go to deep sleep. Naturally, an interrupt will take control and the handler will run, but this won't lead to deep sleep. If your process keeps control for too long without poking the watchdog, the watchdog will reset you.

George

Post by Andreas Urke
Thanks George,
​​
you were right regarding the power, AONWUCAuxWakeupEvent(AONWUC_AUX_WAKEUP) is the correct one. Regarding the ADC_CLOCK, this is being enabled in AUXADCEnableSync().
I have disabled deep sleep. Furthermore, if I do 4 samples in each etimer event it will fail after a few successful events, while it's fine if I do only 2 samples in each. Am I correct in assuming that as long as my process has not relinquished control (reached PROCESS_WAIT_EVENT or similiar) it can not be interrupted by some other contiki-mechanism e.g. making it go to sleep? If yes, I'm thinking there's something non-contiki stopping the show.
Andreas
Andreas

I tried calling SysCtrlPowerEverything() before enabling the clock and it then gave 1 reading (see code bottom) before the precise hard faults come. Removing PROCESS_PAUSE before every reading gave me ~6 readings.

I think the calls that do it are here: https://github.com/g-oikonomou/cc26xxware/blob/master/driverlib/sys_ctrl.c#L126 <https://github.com/g-oikonomou/cc26xxware/blob/master/driverlib/sys_ctrl.c#L126>
AONWUCAuxWakeupEvent(AONWUC_AUX_WAKEUP);
while(!(AONWUCPowerStatusGet() & AONWUC_AUX_POWER_ON))
{ }
and
AUXWUCClockEnable(ui32AuxClocks);
while(AUXWUCClockStatus(ui32AuxClocks) != AUX_WUC_CLOCK_READY)
{ }

Thinking aloud, it seemed to be some timing - something being turned off after x amount of time.

Entering deep sleep (lpm_drop() in main) forces Aux back off.

I then added SysCtrlPowerEverything() before every reading as well but this only gave me about 40 readings before precise hard faulting (FF6C F00D). Putting the powerEverything()+reading into a 1 sec etimer solved it, and I am now able to get readings reliably. However, setting etimer to very low values, e.g two ticks, will cause hard fault again (FF6C F00D).

Pausing between powering up the aux and taking the reading yields control back to main and the chip may go into deep sleep during the pause. This will turn the aux back off.

So from my perspective the open issues are 1) What should should actually be powered,

So my gut feeling is that all you need to do is make sure Aux is powered up and clocked immediately before you trigger a reading.

2) Understand why it fails at rapid reading.

Not sure about that one

AUXWUCClockEnable(AUX_WUC_ADI_CLOCK|AUX_WUC_ANAIF_CLOCK);

I suspect you need the ADC clock too: AUX_WUC_ADC_CLOCK

​Would that be ​PRCM_DOMAIN_PERIPH? (I'm not too familiar at this low level).

It is not the PERIPH PD, the Aux is controlled separately.
George
------------------------------------------------------------------------------
_______________________________________________
Contiki-developers mailing list
https://lists.sourceforge.net/lists/listinfo/contiki-developers <https://lists.sourceforge.net/lists/listinfo/contiki-developers>
------------------------------------------------------------------------------
_______________________________________________
Contiki-developers mailing list
https://lists.sourceforge.net/lists/listinfo/contiki-developers

[Andreas Urke]

Yes, getting there! - basically I have what I need for my usage, but I took
another stab at it:

When spending too much time (doing too many samples, adding many printouts
etc.), it usually fails when disabling the ADC afterwards. So I added a
call to AONWUCPowerStatusGet() before AUXADCDisable() and it sometimes show
both AONWUC_AUX_POWER_ON and AONWUC_AUX_POWER_DOWN set. When this happens
it will crash when acquiring semaphore in AuxAdiDdiSafeWrite(). I tried a
few attempts with enabling the SMPH clock, re-enable AUX/ADC, poking the
watchdog etc. but no luck. Removing the usage of semaphores there will
solve it, but I'll leave that for brave souls.

Looking at TI examples (
https://e2e.ti.com/support/wireless_connectivity/f/538/p/404426/1433112#1433112)
its seems obvious we are missing:

// Disallow STANDBY mode while using the ADC.
Power_setConstraint(Power_SB_DISALLOW);

I could not find out exactly what this does, and I cant find a similar one
in cc26xxware - so I left it at that. I think the current code should suit
most needs, I will post an example once I have cleaned up.

On another note George:
I see there is a new CC13xxware out (
http://processors.wiki.ti.com/index.php/CC13xxWare#Release_notes_v2.00.04.16084).
On the previous version, which is used in Contiki, there is a warning
regarding the radio firmware. Do you know if this firmware is actually
utilized when I flash cc13xx with Contiki? We have had some interesting
tests regarding range (more than ten-fold decrease when compared to TI Long
Range Mode, which I believe is also 50kbps), so I am wondering if this
could explain.

Andreas

Post by George Oikonomou
Andreas, good news - getting there
You are right, for as long as your process is running, the chip won't go
to deep sleep. Naturally, an interrupt will take control and the handler
will run, but this won't lead to deep sleep. If your process keeps control
for too long without poking the watchdog, the watchdog will reset you.
George
Thanks George,
​​
you were right regarding the power,
AONWUCAuxWakeupEvent(AONWUC_AUX_WAKEUP) is the correct one. Regarding the
ADC_CLOCK, this is being enabled in AUXADCEnableSync().
I have disabled deep sleep. Furthermore, if I do 4 samples in each etimer
event it will fail after a few successful events, while it's fine if I do
only 2 samples in each. Am I correct in assuming that as long as my process
has not relinquished control (reached PROCESS_WAIT_EVENT or similiar) it
can not be interrupted by some other contiki-mechanism e.g. making it go to
sleep? If yes, I'm thinking there's something non-contiki stopping the show.
Andreas

Post by Andreas Urke
Andreas
I tried calling SysCtrlPowerEverything() before enabling the clock and it
then gave 1 reading (see code bottom) before the precise hard faults come.
Removing PROCESS_PAUSE before every reading gave me ~6 readings.
https://github.com/g-oikonomou/cc26xxware/blob/master/driverlib/sys_ctrl.c#L126
AONWUCAuxWakeupEvent(AONWUC_AUX_WAKEUP);
while(!(AONWUCPowerStatusGet() & AONWUC_AUX_POWER_ON))
{ }
and
AUXWUCClockEnable(ui32AuxClocks);
while(AUXWUCClockStatus(ui32AuxClocks) != AUX_WUC_CLOCK_READY)
{ }
Thinking aloud, it seemed to be some timing - something being turned off
after x amount of time.
Entering deep sleep (lpm_drop() in main) forces Aux back off.
I then added SysCtrlPowerEverything() before every reading as well but
this only gave me about 40 readings before precise hard faulting (FF6C
F00D). Putting the powerEverything()+reading into a 1 sec etimer solved it,
and I am now able to get readings reliably. However, setting etimer to very
low values, e.g two ticks, will cause hard fault again (FF6C F00D).
Pausing between powering up the aux and taking the reading yields control
back to main and the chip may go into deep sleep during the pause. This
will turn the aux back off.
So from my perspective the open issues are 1) What should should actually be powered,
So my gut feeling is that all you need to do is make sure Aux is powered
up and clocked immediately before you trigger a reading.
2) Understand why it fails at rapid reading.
Not sure about that one
AUXWUCClockEnable(AUX_WUC_ADI_CLOCK|AUX_WUC_ANAIF_CLOCK);
I suspect you need the ADC clock too: AUX_WUC_ADC_CLOCK
​Would that be ​PRCM_DOMAIN_PERIPH? (I'm not too familiar at this low

Post by Andreas Urke
level).

It is not the PERIPH PD, the Aux is controlled separately.
George
------------------------------------------------------------------------------
_______________________________________________
Contiki-developers mailing list
https://lists.sourceforge.net/lists/listinfo/contiki-developers

------------------------------------------------------------------------------
_______________________________________________
Contiki-developers mailing list
https://lists.sourceforge.net/lists/listinfo/contiki-developers
------------------------------------------------------------------------------
_______________________________________________
Contiki-developers mailing list
https://lists.sourceforge.net/lists/listinfo/contiki-developers

[George Oikonomou]

OK so very brief explanation:

AUX = Collection of a number of modules, including the Sensor Controller, the ADC and Semaphores (SMPH)

Their clocks can be gated individually. For example, check how our osc.c first clocks the SMPH module within AUX before using it

When spending too much time (doing too many samples, adding many printouts etc.), it usually fails when disabling the ADC afterwards. So I added a call to AONWUCPowerStatusGet() before AUXADCDisable() and it sometimes show both AONWUC_AUX_POWER_ON and AONWUC_AUX_POWER_DOWN set. When this happens it will crash when acquiring semaphore in AuxAdiDdiSafeWrite(). I tried a few attempts with enabling the SMPH clock, re-enable AUX/ADC, poking the watchdog etc. but no luck. Removing the usage of semaphores there will solve it, but I'll leave that for brave souls.
From what you are saying, I am now convinced that something turns off and pulls the rug from under your feet. The AUX chapter in the TRM used to be somewhat "brief", but the latest revision D clarifies a few things. From what it sounds, you need the AUX powered on and running and the SMPH module clocked.
// Disallow STANDBY mode while using the ADC.
Power_setConstraint(Power_SB_DISALLOW);
I could not find out exactly what this does, and I cant find a similar one in cc26xxware - so I left it at that. I think the current code should suit most needs, I will post an example once I have cleaned up.

This line is part of TI RTOS' power management abstraction. The equivalent is our lpm.h lpm.c. Very very roughly, this is equivalent to our LPM modules and power domain locks. My guess is that this says "Don't standby while we are running and ADC"

I see there is a new CC13xxware out (http://processors.wiki.ti.com/index.php/CC13xxWare#Release_notes_v2.00.04.16084). On the previous version, which is used in Contiki, there is a warning regarding the radio firmware. Do you know if this firmware is actually utilized when I flash cc13xx with Contiki? We have had some interesting tests regarding range (more than ten-fold decrease when compared to TI Long Range Mode, which I believe is also 50kbps), so I am wondering if this could explain.

I am not sure what warning you are referring to. Range issues could be related to our TX power settings, which came straight from Smart RF Studio, but perhaps TI for their long range mode use something different.

George




------------------------------------------------------------------------------

[George Oikonomou]

Post by George Oikonomou

We have had some interesting tests regarding range (more than ten-fold decrease when compared to TI Long Range Mode, which I believe is also 50kbps), so I am wondering if this could explain.

I am not sure what warning you are referring to. Range issues could be related to our TX power settings, which came straight from Smart RF Studio, but perhaps TI for their long range mode use something different.

Or it could be related to RF Front End / Bias settings, which are board-specific. Make sure that in your comparisons you use the same settings in order to get comparable results and that the settings are correct for your board. Ours are in cpu/cc26xx-cc13xx/rf-core/smartrf-settings.c under the configuration of CMD_PROP_RADIO_DIV_SETUP.

.config.frontEndMode = 0x0, /* Differential mode */
.config.biasMode = 0x1, /* External bias*/

Check this one out to see what I mean

http://www.ti.com/product/CC1310/datasheet/application_implementation_and_layout#SWRS1812689

[Andreas Urke]

"pulls the rug from under your feet".

My feelings exactly :) and I believe this is happening outside of the
Contiki LPM - which again leads me to believe Power_setConstraint() does
some config to the modules. I'm thinking finding this and replicating would
be a better solution than re-enabling - will try to revisit this in the
future.

Regarding the warning, see
http://processors.wiki.ti.com/index.php/CC13xxWare#Release_notes_v2.00.03.15980
: "IMPORTANT NOTICE: The "Radio firmware" in this release is a pre-release
version (...)" If this firmware is actually updated and used when I flash
with Contiki I will give the new cc13xxware a try.

Thanks for the other suggestions and ref., I will check it and post if I
find something. Tested on CC1350EM btw.

Andreas

We have had some interesting tests regarding range (more than ten-fold
decrease when compared to TI Long Range Mode, which I believe is also
50kbps), so I am wondering if this could explain.
I am not sure what warning you are referring to. Range issues could be
related to our TX power settings, which came straight from Smart RF Studio,
but perhaps TI for their long range mode use something different.
Or it could be related to RF Front End / Bias settings, which are
board-specific. Make sure that in your comparisons you use the same
settings in order to get comparable results and that the settings are
correct for your board. Ours are
in cpu/cc26xx-cc13xx/rf-core/smartrf-settings.c under the configuration of
CMD_PROP_RADIO_DIV_SETUP.
.config.frontEndMode = 0x0, /* Differential mode */
.config.biasMode = 0x1, /* External bias*/
Check this one out to see what I mean
http://www.ti.com/product/CC1310/datasheet/application_implementation_and_layout#SWRS1812689
------------------------------------------------------------------------------
_______________________________________________
Contiki-developers mailing list
https://lists.sourceforge.net/lists/listinfo/contiki-developers

[George Oikonomou]

My feelings exactly :) and I believe this is happening outside of the Contiki LPM - which again leads me to believe Power_setConstraint() does some config to the modules.

I'm fairly certain it does not. I think the call you quoted earlier is equivalent to one of our lpm_registered_module_t that returns LPM_MODE_SLEEP within its request_max_pm callback

Regarding the warning, see http://processors.wiki.ti.com/index.php/CC13xxWare#Release_notes_v2.00.03.15980 <http://processors.wiki.ti.com/index.php/CC13xxWare#Release_notes_v2.00.03.15980> : "IMPORTANT NOTICE: The "Radio firmware" in this release is a pre-release version (...)" If this firmware is actually updated and used when I flash with Contiki I will give the new cc13xxware a try.

I can't see how that could be relevant, unless other than the "radio" TI have also changed the ADC driver

Thanks for the other suggestions and ref., I will check it and post if I find something. Tested on CC1350EM btw.

CC1350 on what board?

I also realised that I vaguely remember some discussion somewhere saying that in order to get 14dBm TX power with the CC13xx, one had to implement a little "hack". Not quite sure what that hack might be, but perhaps it could be the reason for the differences that you are observing.

Best
George

[Andreas Urke]

"I'm fairly certain it does not." - I believe I checked no Contiki lpm
routines was triggered during the ordeal, but I will check again.

Regarding the warning on the radio firmware, I meant it in relation with
the range issue, not the ADC. If indeed this firmware is utilized I will
re-test with the new cc13xxware.

Sorry for not being clear, I tested a CC1350 Evaluation Module Kit - will
try the CC1310EMK soon, ref. http://www.ti.com/tool/cc1310emk . I had a
quick glance at the Diff. mode and bias, and the config seemed to match the
schematic for the EM cards.

Hack sounds interesting, I will mine the TI forums/doc, please let me know
if you remember anything more in particular.

Andreas

Post by Andreas Urke
My feelings exactly :) and I believe this is happening outside of the
Contiki LPM - which again leads me to believe Power_setConstraint() does
some config to the modules.
I'm fairly certain it does not. I think the call you quoted earlier is
equivalent to one of our lpm_registered_module_t that
returns LPM_MODE_SLEEP within its request_max_pm callback
Regarding the warning, see
http://processors.wiki.ti.com/index.php/CC13xxWare#Release_notes_v2.00.03.15980
: "IMPORTANT NOTICE: The "Radio firmware" in this release is a pre-release
version (...)" If this firmware is actually updated and used when I flash
with Contiki I will give the new cc13xxware a try.
I can't see how that could be relevant, unless other than the "radio" TI
have also changed the ADC driver
Thanks for the other suggestions and ref., I will check it and post if I
find something. Tested on CC1350EM btw.
CC1350 on what board?
I also realised that I vaguely remember some discussion somewhere saying
that in order to get 14dBm TX power with the CC13xx, one had to implement a
little "hack". Not quite sure what that hack might be, but perhaps it could
be the reason for the differences that you are observing.
Best
George
------------------------------------------------------------------------------
_______________________________________________
Contiki-developers mailing list
https://lists.sourceforge.net/lists/listinfo/contiki-developers

[George Oikonomou]

"I'm fairly certain it does not." - I believe I checked no Contiki lpm routines was triggered during the ordeal, but I will check again.

OK yes communication breakdown. I meant I was fairly certain that the RTOS call you quoted doesn't config hardware-specific modules. Could be wrong though.

Regarding the warning on the radio firmware, I meant it in relation with the range issue, not the ADC. If indeed this firmware is utilized I will re-test with the new cc13xxware.

Gocha, I misunderstood!

Hack sounds interesting, I will mine the TI forums/doc, please let me know if you remember anything more in particular.

Pretty certain that all I read was "a hack is needed" without any further details. I'll enquire though.

[Andreas Urke]

Thank a lot! Do you have any thoughts on the cc13xxware: I am uncertain if
the radio firmware is actually updated when I flash with Contiki, or if
this lives in some e.g. a factory set radio ROM which might require some
other flash procedure?

Andreas

Post by Andreas Urke
"I'm fairly certain it does not." - I believe I checked no Contiki lpm
routines was triggered during the ordeal, but I will check again.
OK yes communication breakdown. I meant I was fairly certain that the RTOS
call you quoted doesn't config hardware-specific modules. Could be wrong
though.
Regarding the warning on the radio firmware, I meant it in relation with
the range issue, not the ADC. If indeed this firmware is utilized I will
re-test with the new cc13xxware.
Gocha, I misunderstood!
Hack sounds interesting, I will mine the TI forums/doc, please let me know
if you remember anything more in particular.
Pretty certain that all I read was "a hack is needed" without any further
details. I'll enquire though.
------------------------------------------------------------------------------
_______________________________________________
Contiki-developers mailing list
https://lists.sourceforge.net/lists/listinfo/contiki-developers

[George Oikonomou]

Thanks for sharing, Andreas. More below

The last addition: If allowing DEEP_SLEEP, the AUX semaphore clock also needs to be powered.

OK yes, the ADC code uses ADI8BitsSet() and similar ADI functions and those ultimately use semapahores.

I also used an LPM to set max sleep to SLEEP before starting the procedure, but not sure if this is strictly necessary.

If your code runs in one go (synchronously / without yielding in-between) then doing this should not be necessary.

Another optimization would be to turn off the clocks and AUX afterwards (if they were off before we started).

Those will be turned off automatically next time we drop to deep sleep, but I do agree with you.

Perhaps what we need is an ADC wrapper that automatically fires up AUX and then clocks the necessary modules (which, as you point out in your snippet, are ANAIF, the ADI MUX and SMPH). This would not be dis-similar to what we've done with our oscillators.[ch], in case you have been following the respective thread.



------------------------------------------------------------------------------