Forums

Issue with building Flash Monitor with latest IAR-Kickstart?

Started by John Porubek December 28, 2008
Hello,

I'm having problems getting the Flash Monitor from the TI appnote
slaa341 (which was built with IAR Embedded Workbench Version: 3.41A)
working using the latest IAR-Kickstart downloaded from the TI website
(slac050t.zip IAR-Kickstart v 5.13 7/25/2008) in December. The
program assembles OK and can be downloaded to my target system - the
Softbaugh DLR169 board (which the appnote software said it targeted).

Using TeraTerm to monitor the serial port, I see the "?" being echoed.
However, when I enter a command, say "d", the program echoes a strange
character, $F6 in this case (the divide symbol in my charset).

I searched my archive of saved messages from this group and found one
from emastroman (05Jul07) that may help later on, and one from Mike
Raines (11Aug08) that even addressed a problem with serial
communications, but, alas, didn't apply in my case.

I've begun to troubleshoot the problem using the debugger, but was
just wondering if anyone else had run into a similar problem with this
monitor program (which should be a fairly common starting point).
Additionally, suggestions from those more familiar with the IAR tools
on how to proceed with troubleshooting would be appreciated. I'm
admittedly just a weekend hobbyist. My plan is to modify the program
slightly to support a "3 instruction Forth" interface.

John

Beginning Microcontrollers with the MSP430

Hi John,

I'm not familiar with that code base, but my first debugging step would
be to see if there is any assembler-modules (.s43, for example) in that
source code. If so, these will have to be ported to the new calling
convention in the later versions of IAR. Let me know if that is the
case and I can give some further pointers.

And thanks for using our DIr169 board. That's a little piece of
history.

Tom

On Mon, Dec 29, 2008 at 9:46 AM, Tom Baugh wrote:
> Hi John,
>
> I'm not familiar with that code base, but my first debugging step would
> be to see if there is any assembler-modules (.s43, for example) in that
> source code. If so, these will have to be ported to the new calling
> convention in the later versions of IAR. Let me know if that is the
> case and I can give some further pointers.
>
> And thanks for using our DIr169 board. That's a little piece of
> history.
>
> Tom
Hi Tom,

Thanks for responding. There is indeed an assembler module. The entire
program is contained in flash_monitor.s43. So I would definitely be
interested in further pointers on porting to the new calling
convention. IAR includes a migration guide in the documentation, but
it seems to only address issues with C language upgrades from versions
1.x and 2.x, so I didn't pay much attention to it.

The Dlr169 is a cool little board. I got it at a one-day training
class, along with a Softbaugh FETP, which seems a little strange
considering it was an official TI class.

By the way, I recently purchased your book "MSP430 State Machine
Programming" and have started to work my way through it. I was
thinking about implementing your Flash Monitor program also, but
decided to try the official TI monitor first since I thought I'd have
a greater chance of success. Ha!

John

> The Dlr169 is a cool little board. I got it at a one-day training
> class, along with a Softbaugh FETP, which seems a little strange
> considering it was an official TI class.
>
> By the way, I recently purchased your book "MSP430 State Machine
> Programming" and have started to work my way through it. I was
> thinking about implementing your Flash Monitor program also, but
> decided to try the official TI monitor first since I thought I'd
have
> a greater chance of success. Ha!

If that strategy worked consistently I wouldn't have a company!

Anyway, the big difference in those IAR versions is that the
registers are munched around for mixed-language programming.

Old:
First Param: R12 or R13:R12 for DWORDs
Second Param: R14 or R15:R14
Next Params: On the stack

New:
First Param: R12
Second Param: R13
Third Param: R14
Fourth Param: R15
Next Params: On the stack

So, swapping R13 for R14 is a good first start.

Note that this only applies if C functions call assembler functions.

If that isn't it, use my book ;-)

Tom

John,

Did you make any change to the code in slaa341.zip?

That code assumes the DCO is at 750kHz and generates the 9600 b/s
baudrate accordingly. This could be way off and result in the problem
you have seen.

Your board has a crystal. Correct? You should modify the code and take
advantage of the more accurate frequency of the crystal controlled
oscillator.

Compiler version has nothing to do with your problem. You are not even
using the compiler.

-- OCY

--- In m..., "John Porubek" wrote:
>
> On Mon, Dec 29, 2008 at 9:46 AM, Tom Baugh wrote:
> > Hi John,
> >
> > I'm not familiar with that code base, but my first debugging step
would
> > be to see if there is any assembler-modules (.s43, for example) in
that
> > source code. If so, these will have to be ported to the new calling
> > convention in the later versions of IAR. Let me know if that is the
> > case and I can give some further pointers.
> >
> > And thanks for using our DIr169 board. That's a little piece of
> > history.
> >
> > Tom
> Hi Tom,
>
> Thanks for responding. There is indeed an assembler module. The entire
> program is contained in flash_monitor.s43. So I would definitely be
> interested in further pointers on porting to the new calling
> convention. IAR includes a migration guide in the documentation, but
> it seems to only address issues with C language upgrades from versions
> 1.x and 2.x, so I didn't pay much attention to it.
>
> The Dlr169 is a cool little board. I got it at a one-day training
> class, along with a Softbaugh FETP, which seems a little strange
> considering it was an official TI class.
>
> By the way, I recently purchased your book "MSP430 State Machine
> Programming" and have started to work my way through it. I was
> thinking about implementing your Flash Monitor program also, but
> decided to try the official TI monitor first since I thought I'd have
> a greater chance of success. Ha!
>
> John
>

John,

Mistake in my previous msg.

For F1xx, the code actually assumes you have a watch crystal (32768Hz)
at XIN-XOUT. Do you have that? Does it work correctly? Can you check
the ACLK frequency?

-- OCY

--- In m..., "old_cow_yellow"
wrote:
>
> John,
>
> Did you make any change to the code in slaa341.zip?
>
> That code assumes the DCO is at 750kHz and generates the 9600 b/s
> baudrate accordingly. This could be way off and result in the problem
> you have seen.
>
> Your board has a crystal. Correct? You should modify the code and take
> advantage of the more accurate frequency of the crystal controlled
> oscillator.
>
> Compiler version has nothing to do with your problem. You are not even
> using the compiler.
>
> -- OCY
>
> --- In m..., "John Porubek" wrote:
> >
> > On Mon, Dec 29, 2008 at 9:46 AM, Tom Baugh wrote:
> > > Hi John,
> > >
> > > I'm not familiar with that code base, but my first debugging step
> would
> > > be to see if there is any assembler-modules (.s43, for example) in
> that
> > > source code. If so, these will have to be ported to the new calling
> > > convention in the later versions of IAR. Let me know if that is the
> > > case and I can give some further pointers.
> > >
> > > And thanks for using our DIr169 board. That's a little piece of
> > > history.
> > >
> > > Tom
> >
> >
> > Hi Tom,
> >
> > Thanks for responding. There is indeed an assembler module. The entire
> > program is contained in flash_monitor.s43. So I would definitely be
> > interested in further pointers on porting to the new calling
> > convention. IAR includes a migration guide in the documentation, but
> > it seems to only address issues with C language upgrades from versions
> > 1.x and 2.x, so I didn't pay much attention to it.
> >
> > The Dlr169 is a cool little board. I got it at a one-day training
> > class, along with a Softbaugh FETP, which seems a little strange
> > considering it was an official TI class.
> >
> > By the way, I recently purchased your book "MSP430 State Machine
> > Programming" and have started to work my way through it. I was
> > thinking about implementing your Flash Monitor program also, but
> > decided to try the official TI monitor first since I thought I'd have
> > a greater chance of success. Ha!
> >
> > John
>
On Tue, Dec 30, 2008 at 4:18 PM, Tom Baugh wrote:

> If that strategy worked consistently I wouldn't have a company!
>
> Anyway, the big difference in those IAR versions is that the
> registers are munched around for mixed-language programming.
>
> Old:
> First Param: R12 or R13:R12 for DWORDs
> Second Param: R14 or R15:R14
> Next Params: On the stack
>
> New:
> First Param: R12
> Second Param: R13
> Third Param: R14
> Fourth Param: R15
> Next Params: On the stack
>
> So, swapping R13 for R14 is a good first start.
>
> Note that this only applies if C functions call assembler functions.
>
> If that isn't it, use my book ;-)
>
> Tom

Tom,

This is good information to keep in mind in the future if I have C
functions call assembler functions. However, the flash monitor is
written entirely in assembler (so maybe the IAR tool version is
irrelevant). I hope to be able to spend more time debugging soon to at
least convince myself whether it is a software problem or a hardware
problem. I guess I wouldn't learn as much if it worked right away!

Thanks again,

John

On Tue, Dec 30, 2008 at 7:06 PM, old_cow_yellow
wrote:
> John,
>
> Mistake in my previous msg.
>
> For F1xx, the code actually assumes you have a watch crystal (32768Hz)
> at XIN-XOUT. Do you have that? Does it work correctly? Can you check
> the ACLK frequency?
>
> -- OCY
>
> --- In m..., "old_cow_yellow"
> wrote:
>>
>> John,
>>
>> Did you make any change to the code in slaa341.zip?
>>
>> That code assumes the DCO is at 750kHz and generates the 9600 b/s
>> baudrate accordingly. This could be way off and result in the problem
>> you have seen.
>>
>> Your board has a crystal. Correct? You should modify the code and take
>> advantage of the more accurate frequency of the crystal controlled
>> oscillator.
>>
>> Compiler version has nothing to do with your problem. You are not even
>> using the compiler.
>>
>> -- OCY

Hi OCY,

You had my hopes up at first. It would have certainly explained what I
was seeing. But then I thought "this app was targeted towards the
exact board that I have." It made no sense.

This board does indeed have a 32768 Hz crystal connected to XIN-XOUT.
I'll have to check if it is functioning correctly. Stupid question
without looking into things further: How do you check the ACLK
frequency?

Thanks for your help,

John

Even if the 32768Hz ACLK is working correctly, using it to get 9600
b/s is very risky. Can you try a lower baudrate? For example, 2400 b/s:

To do that, change the lines:
mov.b #3,&U_BR0 ; 32768/9600 = 3.41
mov.b #000h,&U_BR1 ;
mov.b #04Ah,&U_MCTL ; Modulation
into:
mov.b #13,&U_BR0 ; 32768/2400 = 13.65
mov.b #000h,&U_BR1 ;
mov.b #06Bh,&U_MCTL ; Modulation

--- In m..., "John Porubek" wrote:
>
> On Tue, Dec 30, 2008 at 7:06 PM, old_cow_yellow
> wrote:
> > John,
> >
> > Mistake in my previous msg.
> >
> > For F1xx, the code actually assumes you have a watch crystal (32768Hz)
> > at XIN-XOUT. Do you have that? Does it work correctly? Can you check
> > the ACLK frequency?
> >
> > -- OCY
> >
> > --- In m..., "old_cow_yellow"
> > wrote:
> >>
> >> John,
> >>
> >> Did you make any change to the code in slaa341.zip?
> >>
> >> That code assumes the DCO is at 750kHz and generates the 9600 b/s
> >> baudrate accordingly. This could be way off and result in the problem
> >> you have seen.
> >>
> >> Your board has a crystal. Correct? You should modify the code and
take
> >> advantage of the more accurate frequency of the crystal controlled
> >> oscillator.
> >>
> >> Compiler version has nothing to do with your problem. You are not
even
> >> using the compiler.
> >>
> >> -- OCY
>
> Hi OCY,
>
> You had my hopes up at first. It would have certainly explained what I
> was seeing. But then I thought "this app was targeted towards the
> exact board that I have." It made no sense.
>
> This board does indeed have a 32768 Hz crystal connected to XIN-XOUT.
> I'll have to check if it is functioning correctly. Stupid question
> without looking into things further: How do you check the ACLK
> frequency?
>
> Thanks for your help,
>
> John
>

On Wed, Dec 31, 2008 at 7:03 PM, old_cow_yellow
wrote:
> Even if the 32768Hz ACLK is working correctly, using it to get 9600
> b/s is very risky. Can you try a lower baudrate? For example, 2400 b/s:
>
> To do that, change the lines:
> mov.b #3,&U_BR0 ; 32768/9600 = 3.41
> mov.b #000h,&U_BR1 ;
> mov.b #04Ah,&U_MCTL ; Modulation
> into:
> mov.b #13,&U_BR0 ; 32768/2400 = 13.65
> mov.b #000h,&U_BR1 ;
> mov.b #06Bh,&U_MCTL ; Modulation

OCY,

Happy dance! After implementing your changes, I was no longer seeing strange
characters. Then, after heeding the previously ignored line in the
documentation: "All commands and hexadecimal values must be entered in upper
case", the monitor actually worked.

My original mistake was in assuming that this was a proven design. Since my
particular instantiation didn't work, good troubleshooting practice dictated
that I ask "What changed?". Hence my original question about IAR Kickstart
versions. However, another good troubleshooting rule is to always question
your assumptions! Had I started this project from scratch, I might have
realized that 32 kHz is too low a frequency for generating a reliable baud
rate clock for 9600 baud.

My next step is to get the C demonstration application program in the
appnote running as well. In this case, the difference in Kickstart versions
may well come into play. I'm expecting problems, but, hopefully, I'll be
able to sort them out on my own. If not, I'll be back!

Thank you again for your time and invaluable assistance.

John