SH8 and ADC

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

SH8 and ADC

2,744 Views
RobG
Contributor II
Having strife with ADC operation in the SH8 running at Vdd = 3V. I have a few other SH8 applications running ADC with identical configuration settings and no problems. All developed with Cyclone Pro and ICDHCS08. But the others are 5V. Even though in each application Vdd is not supplied via Cyclone Pro the appropriate Cyclone voltage level is selected.
 
The problem is the application stops responding up after a short time (seconds) . Halting operation within ICDS08 shows that coco,adcsc1 bit is not setting so it is staying in the loop
"adcloop   brclr    coco,adcsc1,adcloop"
 
All mcu configuration registers are default except for no cop and adc is 10 bit. The application also stops operating as above if it's started manually (not via ICDS08) but while still connected to the cyclone pro via the bkgd line and gnd. No reset line or vdd. In all cases mcu vdd is supplied separately and not via Cyclone Pro.
 
To get the mcu to run without failing I just disconnect the bknd line from the Cyclone and restart.
 
As mentioned, the only difference between this application and others that don't give trouble is that this is a 3V application.
 
Rob
 
 
Labels (1)
0 Kudos
7 Replies

726 Views
Problem99
Contributor I

 

Hi Rob,
I've no direct resolution to your problem.
But maybe some ideas...

But I have quite similar effects on a QD4 part, which I want to operate at variable Vdd in range  3.0 Volt ...  or  4.5 ... 5 Volt.

I use Cyclone Pro, feed power from my variable power supply to power-in-jack of CyclonePro.
From power-out-jack, the connection goes to Vdd of my target.
Only jumper no. 5 of CyclonePro is selected.
I made a support request to PE Micro (supplier of CyclonePro) and they did tell me that this is the right connection.

1.)  Debugging ADC with active BDM

My function on QD4 should measure it's Vdd, by use of the known internal bandgap reference.
10 bit ADC mode is used.
In general, this works.

But I've found that there ist a lot of traffic on the BDM line.
This results in a significant noise (ripple) also on the Vdd and makes the measurement UNUSABLE, when BDM is connected.
This does also taking place when in "RUN" mode , even if no debug window is selected for periodic update.
I've not made final tests, if all these windows are manually put into "frozen" state...

This means: Debugging of small ADC signals, espacially Vdd, is hard to be done with active BDM traffic.
I've not found a option like "disable BDM traffic when in RUN mode".


2.) Endless waiting for COCO with single-step:

I also have the problem you wrote about:
...
   92: while (!ADCSC1_COCO)  { ; /* wait */ }
0000FA43 0F10FD   BRCLR  7,0x10,*+0       ;abs = 0xFA43
...

In single step mode, the debugger always wait endlessly in the BRCLR loop...
But: This is independent from Vdd , at my target.

--> Maybe the other windows in real-time-debugger ( e.g. "memory" ) does disturb the COCO flag reading, especially when pointing to the area of the internal io registers.
This suspicion I have.

3.)  Other debugging problems and hints:

Also, my activated  PWM output signal stops in debug mode ... I don't know if this is normal behaviour.
I've not found any option like  "don't stop peripherals in single-step mode".


Another point is, that there is only a single breakpoint.
If a breakpoint is set by me, single-step is possible, but no "step out". For this feature, a temporary  breakpoint  would be required, which is not available any more...


Rob, if you have different effects on 3V vs. 5V, also look to the settings (and defaults) for low voltage detect.
On my QD4, this is SPMSC2_LVDV , SPMSC2.


My conclusion is: Very hard debugging for these small uP.
And strange behaviour sometimes.


===>  If somebody else is reading this message, and does have some ideas or knowledge about the debugger, please ANSWER !

Klaus


0 Kudos

726 Views
RobG
Contributor II
Thanks for sharing your experience Klaus.
I have also noted the fact that adc doesn't work in single step mode. But I'm not concerned about this. I can always skip past the adc call to get a reading while step debugging.
 
I have checked for things like resets (for whatever reason) and it's not that. Definetly what's happening is that the coco bit is not setting. I'm not greatly concerned about this issue as it has not overly hindered developement of this 3 volt application.
 
But I was curious and am pleased that someone else has seen similar issues so it's not just me.
 
The adc reading I was doing in this app is reading an external signal. But another application I am working on has on the todo list the job of monitoring vdd via adc using bandgap ref so I will be keen to see how that works out in the debugger. Although this particular app is 5 Volt Vdd.
 
Thanks again
 
Rob
0 Kudos

726 Views
RobG
Contributor II
I have received a reply to this same problem posted on the P&E forum. Turns out that the problem was due to ADCRH register being displayed in the variables window.
 
I simply deleted it from the variables window and hey presto, problem solved. To display the value of the ADCRH I have simply saved it to another ram variable ADCData and displayed that in the variables window.

Having realtime feedback from the MCU while running in ICDHCS08 is a great improvement but it seems there are limitations. This issue would seem to be one such limitation. It's probably documented somewhere. In which case shame on me for not reading it. If there is such info would someone like to point it out please.

Rob
0 Kudos

726 Views
JimDon
Senior Contributor III
I don't know that it is documented per se, as it is really not a tool problem. If you ask the tool to read a register it does.
I think the real question is should status bits be reset on read, or reset by an acknowledge command.

Of course it has been mentioned here many times, and if single stepping the code breaks it, then you can be sure that putting a watch on it will as well.




0 Kudos

726 Views
RobG
Contributor II
I take your point Jim. But I'm not sure that it's intuative to assume that because single stepping doesn't work that running code at full speed should also fail when certain data registers are being watched. This SHOULD be documented in my opinion. Whether this is just a tool problem or if it's inherrant to the HCS08 debugging system I don't know. I don't use CW so I can't test it in that debug interface.
 
The assistance I got on the P&E forum (acknowledgement to Juan) stated that adc control registers should not be displayed in memory windows. But it isn't the control registers in the memory windows that cause the failure of the conversion complete flag being set at the end of conversion.
 
These memory windows are not being updated while code is running anyway so it's not the issue.
 
Neither is it the control registers. I have found that including ADCCFG and/or ADCSC1 control registers in the variables window does not cause the problem either.
 
It's only if either of the adc data registers are watched in variables window that the problem occurs.
 
It doesn't matter if ADCRH is displayed as byte or word, exectution halts. And if ADCRL only is displayed as a byte execution still halts.
 
Anyway problem is now solved and a workaround solution found. It's now back to finding my own bugs and faults.
 
Rob
0 Kudos

726 Views
bigmac
Specialist III
Hello Rob,
 
According to the datasheet for the SH8, the COCO bit "is cleared whenever ADCSC1 is written or whenever ADCRL is read."  The latter would seem to explain your issue.  Even though the watch display may not be updated, perhaps the register is still being read.
 
A similar problem can occur for any peripheral where a read process alone can clear a flag that is being polled within a wait loop.  Possibly you might not have a problem when an interrupt is generated.  There can also be other unintended flag clearing issues for some peripherals, where read-modify-write instructions are used, and where multiple flags are present within the register.
 
Since the problem is related to the way in which specific peripheral hardware within a specific MCU operates, I would think that the device datasheet is the more appropriate place where this behavior is documented - as it already is for the device in question.
 
Regards,
Mac
 
0 Kudos

726 Views
RobG
Contributor II
Hi Mac,
Thanks muchly. I had read about the clearing of coco by reading ADCRL but it didn't click that the background debug module was doing it. Not sure if you are familiar with IDCHCS08 but when program is running, code, memory and cpu windows are not updated till execution is halted but variables are updated while running. Very useful feature that. But it caught me out when trying to directly display ADC data register.
 
Anyway, all sorted now and I have learnt another lesson. Don't just read the user guide, understand it!!
 
Cheers
Rob
 
 
 
 
 
 
0 Kudos