• State Not Answered
  • Locked Locked
  • Replies 7 replies
  • Subscribers 21 subscribers
  • Views 1219 views
  • Users 0 members are here
2025 survey

We are running a survey to help us improve the experience for all of our members. If you see the survey appear, please take the time to tell us about your experience if you can.

Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

MCB-STR 9 running problems

Leon Pretorius

Hello everyone,

The program with several source files and it compiles fine and there is no problems writing to flash memory.

Initially, the main() program only writes some characters to the LCD. If I run it, all is well.

Problems arise when I add a function (very long one) after the LCD.

int main (void) {

  /* LCD Setup                                                                */
        GPIO8->DDR       = 0xFF;                /* P8.0..7 Outputs (LCD Data)       */
        GPIO9->DDR       = 0x07;                /* P9.0..2 Outputs (LCD Control)    */

        lcd_init();
        lcd_clear();
        lcd_print ("Test");

        init_EPL();

}

When the application starts on the eval-board the LCD is frozen (nothing is written to the LCD). Its as if the code didnt even make it to the lines where the microcontroller writes to the LCD. But when I remove the function again the application runs fine.

I realize this is a long shot, and that this might be way too little information for you to be able to help me, but I have no idea on how to fix this problem and I am just looking for some suggestions or any ideas.

Thank you and regards,
Leon

Parents
  • 0 in reply to Leon Pretorius

    "Simulator or debugger?
    (PS, what is the difference exactly?)"

    Different things. The debugger can be used with a simulated ARM. And with the ULINK, the debugger can also be used with your real hardware.

    Since you have a ULINK, you can test both ways. If you set a breakpoint at the start of main() - will you reach this breakpoint when using the simulator? Will you reach this breakpoint when running on the live hardware?

    Since you get stuck in the startup code, it would be best if someone who have been using a similar processor to yours could help out a bit. I have only worked with the NXP chips, and they have different startup files since they have different peripherial devices around the ARM core.

    If the PLL fails to lock on on the real hardware, you may have specified a too high or low PLL multiplier, resulting in a PLL frequency outside the allowed limits. It can also be the result of the clock crystal (or if it is an RC oscillator) for some reason not producing any oscillation at all, or running very unstable.

Reply
  • 0 in reply to Leon Pretorius

    "Simulator or debugger?
    (PS, what is the difference exactly?)"

    Different things. The debugger can be used with a simulated ARM. And with the ULINK, the debugger can also be used with your real hardware.

    Since you have a ULINK, you can test both ways. If you set a breakpoint at the start of main() - will you reach this breakpoint when using the simulator? Will you reach this breakpoint when running on the live hardware?

    Since you get stuck in the startup code, it would be best if someone who have been using a similar processor to yours could help out a bit. I have only worked with the NXP chips, and they have different startup files since they have different peripherial devices around the ARM core.

    If the PLL fails to lock on on the real hardware, you may have specified a too high or low PLL multiplier, resulting in a PLL frequency outside the allowed limits. It can also be the result of the clock crystal (or if it is an RC oscillator) for some reason not producing any oscillation at all, or running very unstable.

Children
No data