HCS08 SH8 MCU works only correctly in debug mode

[i_kauf]

Hello @ll!

I use an 10Mhz external crystal source, 5Mhz Busclock. All works fine during debugging my target under CW 6.3 Special edition. My program is written in assembler and prints a serial ASCII string out for test purposes. My OS is Win XP SP3 and I have a quad core computer.

But after powering up the target MCU again the SCI module prints a lot of trash out. Not my ASCII string. During debugging all was fine.

I also programmed a small delay after initialization of the external crystal source. Cause it could be a problem, the crystal need some time for starting oscillating. I also checked the waveform from the crystal on my scope during debugging and after a power on. Both cases look the same. 

Any ideas?

Best regards,

Ingo-Michael

[bigmac]

Hello Ingo-Michael,

Is it possible that you are attempting to output ASCII data prior to the external reference becoming stable and then switching to FBE mode?  Since prior to this occurring, an untrimmed internal reference would be utilised for FEI mode, the serial baud rate would unlikely be correct prior to the switch occurring.

Regards,

Mac

[i_kauf]

Hello Mac!

I found out that if I send a single Char then it works normal also if my target powers up again.

I get only problems if the complete string is send.

Do you have an idea?

Regards,

Ingo

[ThaManJD]

I'm wondering about the following snippet from your code:

SCI_write:            jsr TDREF            lda SCITXDATA            sta SCID            rtsTDREF:            jsr TDREF_clr            brclr 7,SCIS1,TDREF            rtsTDREF_clr:            bclr 7,SCIC1            rts

I'll assume you meant to clear the Transmit Data Register Empty Flag in the status register and not the LOOPS bit in the control register? typo? SCIS1 <-> SCIC1.

I suspect that when you are sending your string of bytes front to bumber that you are continuously overwriting the UARTs TX buffer. This is because it looks like you never actually clear the flag.

I'm not sure what debugger you are using but if you are "stepping" through your code then the serial string may appear to succesfulyy send since there may be just enough time between steps for the byte to have transferred before the next one gets loaded. But perhaps you get a different experience running real time.

JD

[i_kauf]

Hello JD!

I changed my sendroutine to:

SCI_write:
           
            brclr 7,SCIS1,*      

            MOV SCITXDATA,SCID
            rts

but this was not the problem. I found that the string must be initialized in ROM area. Since I changed the Stringlocation to ROM, the program runs very well.

I do not know why this was the solution. May you can explain it to me?

Regards,

Ingo

[ThaManJD]

Ingo,

yeah i figured the memory placement would have been the main thing.

I'd welcome someone elses comments here. My comments below feel right but i stand ready to be corrected.

By the way,  i'm surprised your compiler did not show this as an error or at least a warning.

ORG    Z_RAMStart  signifies that the following items should be placed in RAM in sequential incrementing order starting at the address defined by the EQU (equate define) Z_RAMStart.

ORG    ROMStart  signifies that the following code,tables or other constants will be placed into ROM in sequential incrementing order starting at the address defined by the EQU (equate define) ROMStart

I'm interested to see what the comiler actually did with your declaration of an "initialised" string in the RAM space.

Usually i would just declare some likely RAM space for the string with a bit of head room(if its a variable).

Ordinarily in assembly I would normally initialise variables with intial values whether bytes, words or strings during an initialisation subroutine. In the case of a string it would come from a table somewhere in ROM.

In Ansi C compiled code, you can initialise a string at the same time you declare it. But for instance in the case of global variables, the compiler puts the value into some space in ROM. A helper routine copies them from ROM into RAM before your program reaches the main entry point.

Unless you do the same sort of thing in assembly, if the compiler is actually reserving an amount of space for your string variable, the data for that string is probably random and unpredictable. One routine that many people run during startup in assembly is to clear the RAM with some value (often 0x00 but not necessarily). I can't see, unless ive missed it anywhere where you have cleared RAM during startup of your device. If your program resets because of watchdog, reset button or other, it's quite likely that the RAM will not change since you restarted.

OK still with me? I get the feeling that your degugging software is being nice to you and initialising your string in the RAM space for you using commands outside of your program(even though maybe it shouldn't?).  I think when you use it without the debugger, the debug software is no longer there to manipulate the RAM.

I notice that when the string was declared and initialised in RAM that it was the last "variable" in the list.

Your compiler should generate some sort of list file that should show what RAM addresses variable were assigned to and how many bytes they actualy took up.

I still wonder how many bytes were reserved by the comiler for the string. I further wonder whether if you had declared any variables after the string whether they would have been safe from being overwritten.

What do you and others think?

JD

[i_kauf]

Hello JD, Hello Mac!

I use CW Special edition which is always at the Demo Board Packages from Freescale included. CW is not Limited to assembly language. I think for my self that Code Warrior should output an error message if such an case comes up.

There is an Motorola application Note AN1752 REV1 available which tells no suggestions about placing a string. May it could useful for other people like me if there would be any information about this application Note.

@JD Yes I am with you. I was working on this problem since one week before asking here. But I am lucky now to fixed it.

 May in a next Codewarrior Version or Update could a popup message integrated which tells that a string should not initialized in RAM. Thank you for investing so much time here!

@MAC I like your explanation very much. This describe exactly what I am thinking now. Thank you too !

 Greetings from Salzburg AUSTRIA/EUROPE,

Ingo

[peg]

Hello Ingo,

Programming in assembly brings with it certain responsibilities. Like knowing the difference between RAM and ROM and being aware of the memory map of the device you are targeting.

It is not normal for an assembler to warn about this. Hell you can normally define a string prior to any org statement and it will just be placed at 0000 - no warnings!

Incidently as you realised the problem was after a POR why weren't you doing this while debugging and then doing a hot re-connect. Now you would have seen the unitialised string in memory and perhaps found out earlier what you had done wrong.

[bigmac]

Hello,

What Peg has said is particularly true for an absolute assembly project where the linker is not used, and the S19 output is generated directly by the assembler.  The inclusion of the ORG directives generally indicates absolute assembly.

For a relocatable assembly project, or a C project, the linker allocates the various sections of code and data to the different memory locations, by making use of the PRM file information.  However, the appropriate segment must still be referenced within the code.

Regards,

Mac

[bigmac]

Hello Ingo,

JD is basically correct.  As this appears to be an absolute assembly project, the CW assembler will generate the S19 file, which would have placed the constant string data at a Z_RAM address.  Then when you programmed the device via the BDM, your string data would have been directly loaded into Z_RAM, and the SCI routine would then work normally for the string output.  After activation of the reset pin, operation should still be normal since the RAM contents are not affected by this type of reset.

However, following a POR the string data will be lost, and the contents of RAM will be random garbage, and this will be output from the SCI.  I think this explains your symptoms.

Your are now obviously aware that the constant string data must reside in flash (ROM), by its placement after the
ORG ROMStart directive.

Regards,

Mac

[i_kauf · Accepted solution]

@ @ll!

I think it works now!!!  I do not understand why but I will show you what I have done:

first my string was here in Z_RAMStart area:

            ORG    Z_RAMStart         ; Insert your data definition here
SCITXDATA:    DS.B    1
IICRXDATA:    DS.B    1
LEDREGISTER:  DS.B    1
Vectorstart:  EQU     $FFC0
ARRAY_SIZE:   EQU     10
RX_BUFFER:    RMB     ARRAY_SIZE
INPOINTER:    RMB     1
OUTPOINTER:   RMB     1
RAM1:         DS.B    1
RAM2:         DS.B    1

Masteranfrage:           dc.b   "X !",$05,$0D,0

then I placed the string to ROMStart area:

            ORG    Z_RAMStart         ; Insert your data definition here
SCITXDATA:    DS.B    1
IICRXDATA:    DS.B    1
LEDREGISTER:  DS.B    1
Vectorstart:  EQU     $FFC0
ARRAY_SIZE:   EQU     10
RX_BUFFER:    RMB     ARRAY_SIZE
INPOINTER:    RMB     1
OUTPOINTER:   RMB     1
RAM1:         DS.B    1
RAM2:         DS.B    1

;Nachrichten

;
; code section
;
            ORG    ROMStart

Masteranfrage:           dc.b   "X !",$05,$0D,0

_Startup:
            LDHX   #RAMEnd+1        ;initialize the stack pointer
            TXS
            SEI                     ;enable interrupts
            lda #%10000000          ;use external crystal
            sta ICSC1
            lda #%00110111
            sta ICSC2

It works now also without debugger and after powering up my target.

Can anyone tell me why this? Is this a common way placing Strings to ROM?

Regards,

Ingo

[i_kauf]

Hello bigmac!

Yes that could also be a problem. But I do not that in my code.

_Startup:
            LDHX   #RAMEnd+1        ;initialize the stack pointer
            TXS
            CLI                     ;enable interrupts
            lda #%00000011          ;Watchdog off,Stopmode off, Resetpin enabled, BDM enabled
            sta SOPT1
            lda #%10000000          ;use external crystal
            sta ICSC1
            lda #%00110111
            sta ICSC2
            jsr delay1              ;external Clocksource needs some time.
            jsr SCI_init
            jsr IIC_init                    ;for PCF8574 Chip
            jsr getaddress            ;read Node address from PCF8574 Chip
            bset 0,PTCDD            ;led red
            bset 1,PTCDD            ;led green
            bset 2,PTBDD            ;RS485 /RX/TX Pin
            
           

mainLoop:
           
            bset 0,PTCD         
            lda IICRXDATA           ;read Address switch
            cmp #$00
            beq masterLoop       ;if Address is zero then act as master
            bra slaveLoop
            bra mainLoop

I tried also the internal oscillator source but I get the same failure. It works in debugging my application and not after powering on my target mcu. Also unchecking the Box "use custom trim reference frequency" in Pemicro Connection Dialog does no effect on this problem.

My SCI init looks like this:

SCI_init:

           
            mov #%00001100,SCIC2
            mov #%00000000,SCIBDH    ;baudreg.-high
            mov #$20,SCIBDL          ;5Mhz
            rts

I worked often with the SCI module on other HCS08 MCU types with near the same code. It seems at this moment that this problem is only on the SH8 device.

I have no idea what is going wrong here. Do you have a code sniped for ICSC1 and ICSC2 adjustments which I can test?

Normally I ever initialize first clocksource and then SOPT Register. After this I initialize my Modules SCI, SPI, IIC. Is this the correct way? 

May you can help? I like the SH8 MCU it is a 5V device and also in DIP Packages available.

The code attached is not ready but you can see that the external crystal source will initialized before the SCI initialization.

Regards,

Ingo

[ThaManJD]

I've used SH8 almost always with serial and have yet to encounter any problems.

If i can make some time this evening, i'll try out your code.

I've got one question/suggestion and one experiment for you in the meantime.

Is the serial interfaced to the same PC as the debugger? Are you sure that cour serial cable connection includes ground?

If it works with the debugger interface connected, you may be getting ground through the debugger but not when the debugger is absent?

As for the experiment, have you inspected the serial signal with your scope? can you make out what length of time a bit time is? maybe try a test where you send capital U over and over continuosly without any break. 'U' is 0x55 so it's an even number of 1's and 0's. Makes it easier to see. If the bit time appears steady, you could work backwards to discover what the UART source clock speed is.

JD

[i_kauf]

Hello ThaManJD!

Thank you for you answer! I tried both. Debugger and Terminal Program on same Computer and separate Computers also. I got the same trouble.

What also confusing me is that I can do after downloading the code to the mcu a reset with the reset button and it works normal after reset. I only get this problem after disconnecting the device from power and reconnecting it again.

I will do some tests with a logic analyzer tomorrow. May I can check the timings.

Regards,

Ingo