Cart New Account Login

HomeAbout usProductsSupportForumsBlogCustomer Service

search inside this forum
SPI will only start transfer when debugger connected on HCS08
Paul M. Sep 22, 2017 at 10:08 AM (10:08 hours)
Staff: Takao Y.

  • I am programming the SPI interface on an HC08AC32 (HCS08) using a PE Micro MultiLink Universal with the ICDHCS08 In-Circuit Debugger Software running on Windows 7. I am using the SPI's Interrupt Service Routine (ISR) to process each byte that is transferred. When I run the program with debugger connected, the SPI starts its transfer after writing a byte to the SPI1D Data Register. But when I run the program with debugger disconnected (booting from power up) the program runs but the transfer does not start. At first I thought it might be the interrupt is not happening but I wrote a special version which blinks a Red LED once per second when the application is running. The clock is incremented once per second from a timer's ISR so that is working as expected. Also, I wrote a special version of the program that polls the SPRF flag of the SPIS (SPI Status Register) and this flag never gets set. So it is my belief that the transfers are just failing to start when writing to the Data Register. Here is a code fragment that shows how the transfer is started: 

    ;Enable SPI1 Master Mode
    MOV #$52,SYS.SPI1C1

    ;Start Transfer
    STA SYS.SPI1D

    ;Enable Interrupt
    BSET 7,SYS.SPI1C1

    Here is a code fragment that shows how the ISR is handled:

    ;Read Status
    LDA sys.SPI1S
    STA 3,SP

    ;Read Byte (This should clear the SPRF flag)
    LDA sys.SPI1D
    STA 2,SP

    ;Rcv Buffer Full?
    LDA 3,SP
    BIT #$80
    BEQ prs_Byt0 ;Skip if not set

    ;Do something with the Byte
    LDA 2,SP
    ...

    The strange thing is that the firmware works when I connect with the debugger and do nothing but press the "Go Button". If the board powers up with the debugger interface not connected, the application runs but the transfers just don't happen. I know that the program is running because the Red LED is blinking as it is supposed to.

    What is it about the debugger that is changing the behavior of the SPI module? Does something happen (to the processor) when the debugger causes it to reset that doesn't happen on a power on reset to make the SPI transfers not work? I will write a service request to NXP (used to be FreeScale and Motorola Semiconductor before that) but my gut feeling tells me that they are going to point the finger at you because the difference is caused by your debugger. Still, the system is not working standalone and that is why I should also write a service request to NXP.

    Earlier I suspected that the problem might be caused by a signal that is not driven when the BDM is not attached. I put a 10K pullup resistor on the RESET line and the behavior is the same with or without the pullup resistor added. The manual says that pullups are placed on both the RESET and the BKGD lines so this is probably not the cause of the problem.

    Any insights are appreciated.




    Comments

  • Greetings,

    Use the code examples from NXP to see if you are able to get their simple project working on your chip:
    http://www.freescale.com/files/microcontrollers/doc/user_guide/HCS08QRUGSW.zip?srch=1

    Although it is in C and not for AC32, you should get a general idea of how it should be set up.


    Takao Yamada

  • I hate it when someone responds and didn't even bother to read my post. If I give too little information they complain that I didn't provide enough information. If I give too much information, they don't even bother to read it because they think it will take too much of their time. I am not about to lay a board out just to develop a whole test application when my application is already working correctly with the debugger connected. It is only the little detail that I describe that isn't working when I boot the board (that I already have) from power on. That is what I need to solve.

  • I want this simple question answered: What does your debugger interface do to an HCS08 processor when you reset it via the reset button on the ICDHCS08 user interface that doesn't happen on cold startup? It is your debugger, not NXP's so you should be able to give me an answer.

  • Greetings,

    I did read your post. The amount of information you gave me is great and I do not have to ask multiple question. I looked into multiple examples projects for multiple hours trying to find a good working solution. The link I gave you is an amazing list of examples for many peripheral for the HCS08 architecture. I have spent more time working on your question than anybody else. So please do not assume that I am just posting a quick link.

    The reason why I want you to try the example project is to determine if you see the same problem. If you see a difference, then you can contrast and compare your code to the example. Example projects are suppose to work out of the box and you should not see any problems.

    The only difference in reset is that the reset button in ICDHCS08 does a soft reset and re-enters background debug mode so that you can continue with your debugging. A hard reset, or power on reset, does not enter debug mode.

    Something to look into is whether you have watchdog timer disabled or enabled in your code. One way to check is monitor your reset line to see if your program is reaching watchdog timer interrupts. Also look into FREEZE bits that prevents timers from running when you are halted in a debug session. These are the only things I can think of that differs in behavior between debug mode and run mode. These S08 devices does not implement any difficult power modes or bootloaders.

    Also note that in debuggers, there is time between stepping or reaching a breakpoint. But in run mode it is running at full speed. Take that into account when running time-sensitive applications.


    Takao Yamada

  • I did look into the sources within SPI_MASTER for both the GB60 and GQ8 modules. There are several symbols that are not defined anywhere. C source code always depends on the quirks and peculiarities of its compiler and I see some peculiarities. In the following function, PTBD_PTBD7 for example, is not defined. However, I suspect that it is just a bit within a byte but C can't manipulate individual bits like this. 

    __interrupt void Vspi_isr(void)
    {
    unsigned char Temp;
    while (PTBD_PTBD2); /* Wait until the clock goes to its default state */
    PTBD_PTBD7 = ~PTBD_PTBD7;
    Temp = SPIS_SPRF; /* Read the SPI Status Register and, */
    ReceivedByte = SPID; /* read SPI Data Reg to ack interrupt */
    ReceivedByte &= 0x0F;
    PTAD &= 0xF0;
    PTAD |= ReceivedByte;
    }

    But in the problem I am seeing, this part of the code would not execute because the ISR never gets called since the transfer never starts. The setup code in the NXP example is somewhat difficult to follow as it is mixed in with the whole system initialization and it uses the same sort of cryptic bit operations(?).

    My system is explicitly disabling the COP. The startup code is so short and simple I can list it here:

    ;Set Stack Pointer
    Start: LDHX #SYS.SysMemTOS
    TXS

    ;Reason for Reset
    LDA SYS.SRS

    ;Disable COP
    LDA #$40
    STA SYS.SOPT

    ;Set Bus Clock to 20MHz
    MOV #$28,SYS.ICGC1
    MOV #$70,SYS.ICGC2

    As for the delays you talk about in a debugger, in both cases where the system works and does not work, I am presuming it is running at full speed either way. I am not setting any breakpoints when in the debugger. I just do a reset and press Go at what I am presuming to be full speed. The difference is whether I am using the debugger or just running from power on reset with no debugger connected. In the latter case, SPI transfers fail to start when writing to the SPI data register. The firmware code is identical in both cases. But that one thing is failing to happen when running from power on reset and it is working correctly when using the debugger. I tried to write an interrupt-driven SPI driver in a previous application and the same thing was happening. I thought that, if I started over fresh and read the manuals again, my result would turn out different but it didn't. Before I just concluded that it was unreliable so I rewrote the module by bit-banging it. But this time I really studied the problem and found out that it only runs correctly when using the debugger. It consistently fails when running from power-on reset and consistently runs correctly when using the debugger. I am now suspecting that the HCS08 SPI module has a hardware design flaw in it. I wrote a service request to NXP but it will take a couple of days before they will even look at it. And their tech support people are not as good as they used to be when it was Motorola.

    So in the meanwhile, I am rewriting the module as a compromise. Full bit-banging is nasty because it is difficult to control the timing of things and it wastes processor time because of the delays. So my compromise is to write it as an auxiliary system off the real time clock. I have the clock interrupts going at 125Hz and the SPI module is written as a state machine. It will handle one bit per clock interrupt. Turns out that the driver isn't as complicated as I feared it would be. I am just about to test it.

    Thanks for your help.

  • By the way, the previous application I was referring to used the MC9S08AC60 which is similar but is a different model and uses a different package size (44 vs 32-pin package).

Add comment


   Want to comment? Please login or create a new PEMicro account.







© 2017 P&E Microcomputer Systems Inc.
Website Terms of Use and Sales Agreement