software forced SOC F28027

David,

To help isolate the problem, do any of the ADC status registers reflect any activity after the ADCSOCFRC is set?  For example, ADCCTL1[ADCBSY], ADCSOCFLG, or ADCSOCOVF?

Are you able to confirm that the TIMER interrupts are being triggered properly?

Would you be able to add writes to unused ADCSOCxCTL registers just before and after the ADCSOCFRC write?  If the program is having trouble writing to ADCSOCFRC, I would expect that it will not be able to write to ADCSOCxCTL either because they are in the same memory space.

-Tommy

Tommy, the ADC never "wakes up", the SOCPRICTL register still holds 0x20 in the RPOINTER field--the reset value. I see no change in any other ADC registers.

In the case of the RAM code, the timer1 interrupt increments a count which is tested in the for(;;) loop. For the ROM code, an interrupt (XINT2) detecting changes on the encoder wheels (and pushbutton) returns a number that is tested in a <switch> statement in the main thread. For both programs the interrupts are behaving as expected. In both cases, the ADCSOCxCTL registers are initialized as expected, but I hadn't tried writing them after the problem appeared in the ROM program--but I will give it a try.

DE

Am I correct in understanding that CPU writes to the ADC registers are not successful when the ADC clock is enabled and EALLOW is set when needed?

Is it possible to halt your program execution from flash during the timer for() loop and manually poke at the ADC registers through the debugger?

David- you didn't say you are trapping, but I wonder if this thread could help?

http://e2e.ti.com/support/microcontrollers/tms320c2000_32-bit_real-time_mcus/f/171/p/140669/751024.aspx#751024

TLee, In my init routine, the lines:

 EALLOW;
 SysCtrlRegs.PCLKCR0.bit.ADCENCLK = 1;
 (*Device_cal)();
 EDIS;

are use to allow clocking of the ADC module and set the calibration. I then proceed to set the SOCxCTL registers for 7 start-of-conversion readings. HOWEVER, subsequent writes to un-used SOCxCTL registers are ignored--both in my code and from within the debugger. From prompting in your email, I took a look at SysCtrlRegs.PCLKCR0 and saw a value of 0x0515--bit 3, the ADC clock enable bit was NOT set. Poking 0x051D into this register allow me to manipulate register values within the ADC.

So the question now becomes, how did that bit get cleared?

bit-10 is set (SCI_A clock enable), but I'm not using this section. bit-8 is set (SPI-A clock enable), but I'm not using this section. bit-4 is set (I2C clock enable), but I'm not using this section. bit-0 is set (HRPWM clock enable), but I'm not using this section. Upon examination, these bits are set by the call to the TI routine InitSysCtrl() in my main_init.c code. I see the ADCENCLK bit set repeatedly within InitSysCtrl() and later set in my ConfigureADCSampling() and set once more in my comparator_init() routine. It should be set.

I'm wondering now if the problem is the read-modify-write sequence needed to manipulate individual bits within a register.

I've been spinning my wheels on this problem for some time. I think it's time to make a rule not to use .bit. notation with any code written for the C2000 controllers . . .

Your thoughts?

Joe, thanks for the input, but I think the problem stems from a "spontaneous" clearing of the ADC's clock enable bit. See my previous post to TLee.

David,

Can you try to set a hardware watchpoint for writes to PCLKCR0?  Hopefully this will help isolate the write that clears the ADCENCLK bit.

I have heard people speak of concerns and complications when using read-modify-write bit operations, but I personally have not had any problems with them in my code.

-Tommy

David,

I'm glad that you were able to resolve the issue.  Sounds like it was not intuitive for the function to modify the ADC clock.  I'll try to look into the history of this.

-Tommy

Tommy, I'm still having trouble with the read-modify-write setting of I/O bits on the F28027. The easiest workaround is to simple write the bits twice. With that, the changes to the I/O pins hold their desired value--the values "stick". Without the change, the pins with change briefly and revert to the previous value. For example the routine below behaves only with double writes. After several variations, I decided to double up the writes everywhere.

My .h file has the variables defined as:

#define     NHD_RS        GpioDataRegs.AIODAT.bit.AIO10

#define     NHD_RWn     GpioDataRegs.AIODAT.bit.AIO12

#define     NHD_E           GpioDataRegs.AIODAT.bit.AIO14

// =========================================================

void NHD_W_and_E(int type){
   // instrument code using XMT_Key, 04sep12
   GpioDataRegs.GPADAT.bit.GPIO28 = 1; // output high, XMT_Key
   DELAY_US(40); // delay 40us
   // flaky I/O, do it twice
   NHD_RS = type; data NHD_RS = type; // RS--register select, 0 => command, 1=> data
   NHD_RWn = 0;    NHD_RWn = 0;  // we're writing
   Bus_Drive();      // output previously set 8-bits
   NHD_E = 1; NHD_E = 1;  // enable high, active high
   DELAY_US(2); // delay 2us
   NHD_E = 0; NHD_E = 0;  // enable low, idle low
   NHD_RS = 0; NHD_RS = 0;  // idle low,
   GpioDataRegs.GPADAT.bit.GPIO28 = 0; // output low, XMT_Key
}
// =========================================================

DE

David,

Have you tried using the AIOSET, AIOCLEAR, and AIOTOGGLE registers?  Writes to these registers tend to be more robust when updating individual GPIO bits.  I think GPIO Data registers are a special case because the bits are used for both control and status.

-Tommy