This thread has been locked.
If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.
Hi,
I converted a project developed using Stellarisware over to TivaWare. Everything still works except for SysCtlADCSpeedSet (and ROM_SysCtlADCSpeedSet). If this function is called, then calling ADCSequenceConfigure results in a precise bus fault. The fault address is the ADC1EMUX register. This can be recreated with the following code snippet:
MAP_SysCtlClockSet( SYSCTL_OSC_MAIN | /*Configure system clock to 50MHz */
SYSCTL_USE_PLL | /* using 200 MHz PLL */
SYSCTL_SYSDIV_4 | /* divided by four */
SYSCTL_XTAL_16MHZ ); /* clocked from 16MHz external crystal */
MAP_IntEnable(FAULT_BUS); /* (If these are not enabled, all of */
MAP_SysCtlPeripheralEnable(SYSCTL_PERIPH_ADC1); /*Enable ADC1 peripheral */
MAP_SysCtlDelay(5); /*Delay a few cycles to ensure ADC is */
/* enabled */
MAP_ADCHardwareOversampleConfigure(ADC1_BASE, 64); /*Configure to oversample 64x */
MAP_SysCtlADCSpeedSet(SYSCTL_ADCSPEED_125KSPS); /*Reduce sample speed to minimum */
MAP_ADCSequenceConfigure( ADC1_BASE, /*Configure ADC sequence 0 on ADC1 so it*/
0, /* is processor triggered, with */
ADC_TRIGGER_PROCESSOR, /* priority 0 (highest) */
0);
Looking at the assembly, the only difference between StellarisWare and TivaWare is the definition for SYSCTL_PERIPH_ADC1. In StellarisWare, it's defined as 0xf0003801, but in TivaWare it's 0x00100002. It looks like ALL of the SYSCTL_PERIPH_* definitions were changed like this (not just the ADC). I haven't attempted to decipher the scary looking macro expansion in SysCtlPeripheralEnable to see exactly what is being set for each of those SYSCTL_PERIPH_ADC1 definitions, but I would think it would just be Bit 1 of the RCGCADC register (0x400FE638) in both cases.
(*((volatile unsigned long *)(((unsigned long)(0x400fe600 + ((ulPeripheral & 0xff00) >> 8)) & 0xF0000000) | 0x02000000 | \
(((unsigned long)(0x400fe600 + ((ulPeripheral & 0xff00) >> 8)) & 0x000FFFFF) << 5) | ((ulPeripheral & 0xff) << 2))))
I'm using an XM4C123GH6PZ and IAR 6.50.5.
Please verify this is a bug or let me know if I need to investigate more.
I need to change my suggestion...
There is an inconsistency between TivaWare and the new documentation. What's happening in your specific situation is that to enable the clock for the ADC, we now go through the RCGCADC register. In previous releases (StellarisWare), clock enable/disable was done through the legacy RCGC0/1/2/etc window. On Tiva, we've deprecated those registers, so references to RCGC0 (this is the one that impacts ADC) are gone. The problem is that writes to RCGC0 are reflected in RCGCADC, but the opposite is not true. So, when you enable the clock for the ADC in RCGCADC, RCGC0 is not updated. When you go along later to set the speed for the ADC, you do a RMW on RCGC0 which, unfortunately, does not show the true status of the clock enable.
So, with all of that info, you have two things you can do. First, you can simply move the call to SysCtlADCSpeedSet() before the SysCtlPeripheralEnable() call. Second, you can manually write the ADC speed, but also include the write to the clock enable bit for ADC1 when writing RCGC0. You can also try writing speed in ADCCC. I thought this register did not allow setting speed in the existing TM4C silicon, but I could be wrong.