i'm using winstar 16*2 char lcd for displaying volume byte on screen.this lcd is interfaced with MC9S08SE8 MCU.i'm controlling the volume by pt2258 .after running the asm program and increasing the volume by remote .it is displaying the correct sequence of volume bytes but when i continue to press the volume button it abruptly stops displaying the correct sequence and displays garbage characters and then the lcd display is turned off. plz help if somebody has any idea if someone has problem understanding the bug ,i can provide asm code.feel free to ask.actually its quite long and will take space.morover the code seems to work fine. i'm attaching the circuit diagram of lcd interface .i2c communication is used between pt2258 volume controller and microcontroller. |
Solved! Go to Solution.
Hello all,
the problem is finally solved.there was a small problem with the detect repeat pulse subroutine in my code.i was totally ignoring it .there was no problem with the circuit.there was no noise issue.it was a small n simple thing that was being ignored.all ur posts helped me learn alot of things.so im highly grateful to u.
thank u all ,
Hi,
Thanks Rocco for your "how Peg managed to confuse himself" explanation.
I took it as using the asterisk with assembler directive as a given. I don't think you can really build a case against using it there!
In my own mind I replace * with the word "here" and only use it like that (with no offsets)
HELLO MAC,
IT TOOK ABIT TIME TO UNDERSTAND UR CODE BUT I MUST SAY IT TAUGHT ME A LOT OF THINGS.IT IS REALLY A VERY MARVELLOUS AND EFFICIENT CODE.I HAVE ALSO TRIED TO THE SAME THING BUT U DID IT USING FEW INSTRUCTIONS.I REALLY LIKED UR CODE.BUT I'M HAVING PROBLEM TO INCORPORATE IT MY ASM CODE.
I WANT THAT THE CODE WORKS CORECTLY FOR ANY mc9s08se8 MCU AND SO I WANT TO CALIBRATE THE MCU IN SUCH AWAY THAT IT GIVES A TRIMMED FREQUENCY THAT WORKS ON ANY mc9s08se8 MICROCONTROLLER.I BELIEVE UR CODE DOES THE SAME.SUPPOSE MY MCU DOESNT OPERATE PROPERLY FOR THE TWO TRIMMED FREQUENCY U HAVE ADOPTED IN UR CODE.THEN HOW CAN I ADJUST IT SUIT MY REQUIREMENT.IS IT POSSIBLE THAT MY CODE FINDS OUT WHAT WILL BE THE ADJUSTMENT FACTOR EACH TIME IT IS RUN ON ANY MICROCONTROLLER OF THE SAID GENRE.I HOPE U UNDERSTAND WHERE I'M GETTING STUCK. PLZ HELP ME OUT..
Hello Amit,
IT is unclear to me what you are trying to achieve.
If you are using a different target frequency than what bigmac has allowed for then simply adjust the delays to compensate.
As the main purpose of the trim register is to compensate for errors in the manufacturing process it is impossible to deduce the target frequency from inside the device.
In the real world you would have a target frequency (or pehaps a few) and the device would be calibrated for these.
You would have to pass the chosen target frequency to the code and act accordingly.
You have to presume that the calibration is done correctly.
You would then calibrate your delays in some way (as bigmac has done, for example)
As for making this some how universal or self calibrating this is impossible without some known reference being applied.
You could calculate the delays based on the passed target frequency, but why would you be using a variable buss frequency?
Hello Mac,
you talked something about TPM channel in ur previous post.i want to give it a try.may be that solves the problem.do u think it will help my cause???
Hello Mac,
i finally learned to incorporate the macros u defined in ur code in my program.it compiled but the lcd is still resetting.i also tried to adjust the trim frequency of the ics.but when im using the mcu in my ckt,the frequency is approximately half of what i trimmed it for.i tried to use different DCO ranges with corresponding BDIV values .the lcd still resets.then i decided to use external clock .but that also fails as a solution.
This problem has tested my patience to the maximum.dont know if theres nething left to try.BUT i would keep trying ,in the meantime if u have nething to suggest i would b more than delighted to try it !
Hello Amit,
The code that I previously posted addressed the issue of the IR decode process only. It did not address your previous LCD reset issue. Setting up the code for a specific bus frequency is critical to the decode process. This would also apply if you were alternatively using a TPM module for timing purposes.
Within the posted code, to adjust the timing to suit a different bus frequency would involve modifying the number of padding cycles so that the basic delay formula (in microseconds) would still be met.
How are you measuring the bus frequency to determine that it is incorrect? Note that the non-volatile trim value needs to be programmed by the USB Multilink Interface, along with the code. Your code must then transfer the non-volatile value into the trim register.
When calculating the bus frequency, did you allow for the additional divide by 2 stage between the DCO output and the bus? This is shown within the bus distribution drawing in the datasheet or reference manual.
Regards,
Mac
Hello all,
the problem is finally solved.there was a small problem with the detect repeat pulse subroutine in my code.i was totally ignoring it .there was no problem with the circuit.there was no noise issue.it was a small n simple thing that was being ignored.all ur posts helped me learn alot of things.so im highly grateful to u.
thank u all ,
Hello MAC,
i feel highly obliged for ur help.although my problem is solved ,i found urir decode code much efficient than mine and im trying to replace my lenghty decode subroutine with the one u posted in this thread.i compiled ur code in absolute assembly mode.im declaring the macros in derivative.inc and calling them from my main.asm of my code.on using the branching and jsr instructions,im getting errors.so i thought of making the subroutines as macros and then calling these macros from the macro(the one im calling from main.asm) itself.this seems to work,but i cant do away with all branching instructions.may be u can help me with the correct implementation of it.thank u once again.
Dear MAC,
Thanks a lot. Im learning a lot while looking into your code & thanks 4 ur previous post.its very kind of u to bear with my ignorance .
i tried to understand ur code and i found 20 percent timing error compensation quite intelligent. i'm having problem understanding following things in ur code ..
1.how will i define low_trim symbol and why are two conditional blocks there for trimming.
ifdef LOW_TRIM
; FEI mode, with reference trimmed for 32.768 kHz.
; FLL factor: 512
; DCO freq.: 32768*512 = 16.777216 MHz
; BDIV factor: 2
; Bus freq.: 16.777216/4 = 4.194304 MHz
else
; FEI mode, with reference trimmed for 39.0625 kHz.
; FLL factor: 512
; DCO freq.: 39062.5*512 = 20.000 MHz
; BDIV factor: 2
; Bus freq.: 20.000000/4 = 5.000 MHz
endif
2. you are using ... TST ,X in
PAD_DLY: MACRO ; Padding delay (cycles) - 12 min.
IF ((\1%4)==3)
TST ,X ; [3].
what are the contents of register X before this instruction.what does this instruction perform here??
..
thanks again.
Hello Amit,
When I first wrote this version of the code (specifically for a 9S08SE8), I was unsure of what ICS internal reference trim frequency I would be using. This was the reason for providing the two possibilities. The snippet that you posted provides only for the selection of the applicable comment block, for documentation purposes. However, within the WAITHIGH and WAITLOW routines, different padding values are selected so as to maintain a consistent delay formula.
You will notice that, prior to the posted snippet, there exists the label LOW_TRIM:, which is currently commented out. This means that the label is undefined, so the ifdef test will be false. For the conditional test to be true, the label would need to be uncommented. However, as you previously mentioned that you were using a 5 MHz bus frequency, it is appropriate to leave as a comment.
The use of the instruction TST ,X does nothing more than provide a further 3 cycles of padding delay, achieved with a single byte of code. The value of X is not important, and is not altered.
Regards,
Mac
Hello,
I have not looked at the code and don't use Codewarrior but I can answer 3 for you.
* represents the current value of the programme counter
The programme counter will generally be the address of the following instruction
*+5 forces it to 5 more bytes on
So this will skip the next few lines, depending what is actually there.
So its a way to do a short branch without a label at the destination
(you can do a long branch up to the instructions limit but it would be painful to read)
peg wrote:Hello,
I have not looked at the code and don't use Codewarrior but I can answer 3 for you.
* represents the current value of the programme counter
The programme counter will generally be the address of the following instructionThe programme counter will be the address of the current instruction (the BEQ)
*+5 forces it to 5 more bytes on
So this will skip the next few lines, depending what is actually there.
So its a way to do a short branch without a label at the destination
(you can do a long branch up to the instructions limit but it would be painful to read)
Hmmmm.. I seem to remember my first attempt at this was a bit confusing, so I changed it to be even more confusing.
Now it is not so early in the morning I have had another go at it.
hello all,
my problem seems to match one in this forum that goes like this..
"Forcing RESET in code - 68HC711K4"posted on 2010-01-15 by rjgardner .the only thing that is different is that my code is in assembly language.plz check the above post and suggest something because i'm really stuck with this bug.waiting for ur replies.
After unexpected reset you could read SRS register. It should tell you what caused last rest, was it LVD reset, COP reset, illegal address ILAD reset, or illegal opcode reset ILOP.
can u please elaborate on how to read srs register
hi kef ,
i saw the contents of srs register ,only the POR bit is set during debugging.the problem is coming in real time , when i'm burning the code in microcontroller and then pressing the volume buttons continuously.at that time how can i see the content of srs register.
Hello Amit,
You normally read the SRS early in your initialisation code.
If it is anything other than POR you latch this and display the problem on your LCD for example.
This way if your MPU is resetting you can discover the cause.
these are the remaining code sections.
Dear All,
I had worked out with your suggestions on this topic but the problem still
persists. I think the problem is in the code section. Some stack issue or like that.
Please suggest ASAP as I don’t have much time to submit my project.
The points that I covered are as below…..
1) Why not feed Vdd from the same 5 volt (regulated?)
2) Like is to control the R/W line of the LCD so it is only write as long as it needs to be (a very short time).
3) If you need to turn off the backlight when Vdd is removed, I suggest that you switch the backlight using a simple transistor or MOSFET switch. If the backlight pins are floating, you could use a NPN or N-channel switch inserted between cathode and ground. The base (or gate) would be switched by the Vdd line.
4) The 100uF bulk capacitor, currently connected across the relay coil, would be better connected between the top of the relay coil and ground. This will then absorb the return current surge when the commutating diode across the relay coil conducts, and will reduce the sluggishness of the relay turn-off due to the capacitor. With the current arrangement there will also be an unnecessary current surge through the transistor switch during turn-on
5) Another likely issue with the relay driver is that you currently provide only about 0.4 mA of base drive current to the BD139. In the worst case this may provide a maximum collector current in the vicinity of 10mA, which maybe insufficient for the relay. In this instance, I might consider a resistor value of 2k2, or maybe even lower. The port pin should use the high current drive setting.
as far as pin 15 is concerned ,i followed the following pdf.
Hello Amit,
nova0809 wrote:as far as pin 15 is concerned ,i followed the following pdf.
The description of pins 15 and 16 within the document are so contradictory, it is useless. I suspect it is a translation problem from Chinese. I assume that pins 15 and 16 operate independently from the remainder of the interface. Using a series resistor to limit the current through the backlight to a few mA, you can experimentally determine what polarity of the 12 volt source is required - the backlight will glow when the polarity is correct.
If you need to turn off the backlight when Vdd is removed, I suggest that you switch the backlight using a simple transistor or MOSFET switch. If the backlight pins are floating, you could use a NPN or N-channel switch inserted between cathode and ground. The base (or gate) would be switched by the Vdd line.
I also notice that the Vdd limits specified within the referenced document are tighter than the previous datasheet. Even more reason that Vdd should be regulated.
With regard to your relay driver circuit, as shown in the most recent schematic, I would suggest a change. The 100uF bulk capacitor, currently connected across the relay coil, would be better connected between the top of the relay coil and ground. This will then absorb the return current surge when the commutating diode across the relay coil conducts, and will reduce the sluggishness of the relay turn-off due to the capacitor. With the current arrangement there will also be an unnecesssary current surge through the transistor switch during turn-on.
Another likely issue with the relay driver is that you currently provide only about 0.4 mA of base drive current to the BD139. In the worst case this may provide a maximum collector current in the vicinity of 10mA, which maybe insufficient for the relay. In this instance, I might consider a resistor value of 2k2, or maybe even lower. The port pin should use the high current drive setting.
Regards,
Mac