Forum : ST7/STM8
Original Post
| Post Information | Post |
|---|---|
|
August 3, 2012 - 7:34pm
|
I've been trying to get the ADC2 working for the STM8S208RB daughter board, attached to the REva 3.3 MB. Most of the Output I've tested (LEDs and LCD screen), as well as the GPIO, but I can't seem to get the ADC2 to read the potentiometer. The POT jumper is in, and I've confirmed that the actual physical potentiometer is working and sending its signal all the way to the MCU (Input 13, PF.7, AIN15 on the STM8S).At first we used our own code that worked for a previous STM8S chip, and received only a zero value from ADC2. Then we tried the |
(I'll try writing this up again. It looks like other people are having issues with their posts getting cut off in this forums)
I've been trying to get the ADC2 working for the STM8S208RB daughter board, attached to the REva 3.3 MB. Most of the Output I've tested (LEDs and LCD screen), as well as the GPIO, but I can't seem to get the ADC2 to read the potentiometer. The POT jumper is in, and I've confirmed that the actual physical potentiometer is working and sending its signal all the way to the MCU (Input 13, PF.7, AIN15 on the STM8S).
At first we used our own code that worked for a previous STM8S chip, and received only a zero value from ADC2. Then we tried the example problem "TestAll" for the stm8 chip. We also received "0" readings from the potentiometer ADC.
The code involving the ADC that we run is:
void main( void ) { /* ADC Init */ GPIO_Init( GPIOF, GPIO_PIN_4 | GPIO_PIN_5 | GPIO_PIN_6 | GPIO_PIN_7, GPIO_MODE_IN_FL_NO_IT ); ADC2_DeInit(); ADC2_ITConfig( DISABLE ); unsigned short retword; retword = 0; while(1) { retword = ADC_ReadPot(); delay(500); } } unsigned char ADC_ReadPot( void ) { unsigned short val = ADC_ReadChannel( ADC2_CHANNEL_15 ); /* Convert to percentage: 0->0, MAX_ADC_VAL->100 */ val = val * ( unsigned long )100 / MAX_ADC_VAL; /* ulong required to avoid overflow */ return val; } unsigned short ADC_ReadChannel( unsigned char channel ) { unsigned short val; /* Configure ADC2 for a single capture on given channel */ ADC2_Init( ADC2_CONVERSIONMODE_SINGLE, channel, ADC2_PRESSEL_FCPU_D2, ADC2_EXTTRIG_TIM, DISABLE, ADC2_ALIGN_RIGHT, channel, DISABLE ); ADC2_Cmd( ENABLE ); ADC2_StartConversion(); /* Wait for end of conversion */ while ( ADC2_GetFlagStatus() == RESET ) ; val = ADC2_GetConversionValue(); ADC2_Cmd( DISABLE ); ADC2_ClearFlag(); return val; }Does anyone have any suggestions on what could be the problem? We've also tried the ADC2 with the TEMP sensor, with similar 0 readings.
Thanks for the help,
-Dan
Hi,
I just retested the P command in the TestAll example here and it works fine. Here are some hints...
Please confirm that you have plugged the POT enable jumper on the motherboard.
Please confirm that you are using the latest versions of the software. (both Ride and RKit-STM8)
Please confirm that when testing using the original example, you used a RS232 connection, and not just the debugger. (see next point below for why I ask this)
Please try to make your retword variable global and volatile. Seeing your code, the variable might have been optimized out, making it impossible to observe during debug.
volatile unsigned short retword; void main( void ) { ...Please try to remove the daughterboard and the POT enable jumper and clean all the contacts. (using a special product or just some dry cloth) Some of these boards were produced quite some time ago and it is possible that they suffered from long stocking on distributor shelves.
Please check using a voltmeter that the voltage on the jumper really changes when yo umove the potentiometer. You might also want to check this directly on the STM8's input pin, but be careful not to make a shortcut with the voltmeter probe.
I hope it helps.
Best Regards,
Vincent
I tried your suggestions, and still read a value of "0x0000 (0)" for the retword during Debug. Now, I could possibly be using the debugger incorrectly, but with the RLink attached through the USB, and the board powered up, I "Start" and then "Run" on the Ride7 compiler. I put a stop point at the delay, and mousing over the "retword" variable, I still see a value of "0x0000 (0)". Now, to make sure it wasn't just the Debugger value, I tried setting the LEDs to the retword value, also with no change.
For each of your bullets:
- POT jumper is connected on MB.
- Latest Ride7 and STM8 Kit are installed (Just re-installed this week)
- I don't have an RS232 connection, nor the software with the terminal to interact with the board, but we will not be using them in the future (we'll use CAN). I know the "TestAll" program was set up to use UART, but all of the ADC2 commands that I've seen should work independently of how the command is entered.
-"retword" is now global and volatile, with no change
- I re-set and cleaned the jumper, and re-set the daugherboard, with no visible damage.
- I've seen the POT signal all the way to the STM8S input lead, so it doesn't look like any of the connections are damaged.
Every other function I've tried (besides ADC2) seems to work. I can output a signal, and no other problems with the STM8S. It would seem strange that only the ADC2 would be damaged. Since it is a relatively simple program, I would have thought the problem is with the debugger, but if I try to transfer the "retword" data to other types of debugger-independent outputs, I still get a value of 0.
Thank you for all of the help so far,
-Dan
Hi,
Thank you for the feedback.
I made more tests and found a bug in the debugger, in the displaying of the values of the variables. We will correct it for the next release of the software. In the meantime, to avoid it you just need to make sure that all your variables names are only used once. If you have two variables with the same name (for example, one local and one global, or two local variables in different functions, or in different sections of a function), then in some cases the debugger displays the wrong one. Note that this bug only concerns displaying in the debugger. The code generated by the compiler is correct. Note also that a variable that is optimized out is not displayed, but this is not a bug. ;)
However, this does not explain why you were not able to have the LEDs changed depending on the potentiometer status. Please follow precisely the procedure below and tell me when (if) it fails (and how), in order to determine the source of the problem...
1. Download and unzip this example project on your hard drive:
ftp://www.raisonance.com/pub/forum/REva_STM8S208_POT_LEDs_120807/TestAll_POT_LEDs.zip
It is a modified version of the TestAll example, which copies the value of the potentiometer to the LEDs.
(I can check yours if you want to send it to )
2. Program (using RFlasher or STM8_pgm) the hex file that I compiled (DO NOT recompile at this stage) to the flash of the device and execute by plugging power OFF and ON. Make sure you have the POT and LEDs enable jumpers plugged. You should see the LEDs turning ON/OFF when you turn the potentiometer. If this fails, then there is a hardware problem. If it succeeds, proceed to the next step.
3. Open the project in Ride and recompile it. Then repeat step 2. (program using RFlasher, execute using POR, turn POT, check LEDs) If this fails, then there is a problem in your project manager or compiler. If it succeeds, proceed to the next step.
4. Open the project in Ride and debug it. Execute it without breakpoint to check that the LEDs change when you turn POT. Then stop it and add a breakpoint in the while(1) loop in the main function. Run again to the break. Try to observe the value of retword using the tooltip, and also using normal watches. If this fails, then there is a problem in your installation of our software. If it succeeds, then probably the bug I mention at the very beginning of this post explains it all, and you should be able to go on by simply making sure that all your variable names are only used once. Of course for inspecting the variables you also often need to make them volatile and/or global, and/or to reduce the optimization level.
Best Regards,
Vincent
Vincent,
Thanks for the modified example project. It looks like the failure is likely hardware. No response from the LEDs, even with the un-recompiled HEX. I followed through the other steps, just to confirm, and both the recompiled HEX, and the debugger, also don't respond. I again confirmed that the POT was working, and I added a "retword++" just to see if the LEDs work (they do), but no response from the ADC.
I've followed the problem down all the way to the ADC2 Control Bits. They are responding to the initialization, changing from the default Left Align, to the set Right Align. They are also setting all the proper flags for ADC Conversion, setting from "Conversion Not Complete" to "Conversion Complete" at the proper Debugger Stops. The data, however, is always 0.
We'll just re-order a new daughterboard, as they are not that expensive. If we continue to have problems from there, we'll let you know. Again, thanks for all the assistance with this problem.
-Dan
Hi,
Thanks for the feedback.
Before changing the board you might want to check that the analog voltage reference pins are correctly soldered: Remove the daughterboard from the motherboard and check the connections of the power (pins 7, 8, 19 and 40 of the STM8 should all be connected to each other) and ground. (pins 4, 5, 20 and 39 of the STM8 should all be connected to each other)
You can also power the board and check that you have 4V7 (or 3V3, depending on your jumper settings) on all 4 power pins. (7, 8, 19 and 40)
If the main power (VDD) is supplied but not the analog reference (VDDA), one might observe what you describe. These connections are tested during production of the board, but a (not-so-)bad connection might have passed the test in the factory and failed later during transport... So with some luck you just have to resolder one pin or two. ;)
Otherwise it looks like the ADC is burned in the STM8. It would take a quite hard electrical stress to do this, but it is possible...
Best Regards,
Vincent
Looks like the connections are good, although I haven't checked the pins for power.
If it is a hardware issue, it likely wouldnt have been during manufacturing or testing. Someone used the board and REva quite a bit 2 years ago, and then it sat on a shelf for 2 years, and then I could have damaged something as well while setting it up the past few weeks, so any physical or electrical damage is likely from us.
-Dan
Hi Vincent,
We received the new board, an STM8S208RB Daughter Board, and the ADC seems to work now. I loaded up your sample project, the original and recompiled, and I am seeing a response for the Potentiometer ADC from both the LEDs and the Debugger watches. So it looks like someone on our side had put too much of an electrical stress on the old board at some point.
Thanks again for the help,
-Dan