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

Keil freezing coming out of debug

I have a really simple program, a modified Blinky, that everytime round the loop jumps off to read in from U0RBR and outputs the character found through UART1. UART0 is mapped in take it's input from COM1. It works perfectly, but has a slight glitch that is stopping Keil from leaving debug smoothly. If data is received in U0RBR then when I click on the 'd' to leave debug Keil freezes. All the toolbar buttons, except the 'd' disappear and the only way I can exit it to dump out of Keil. If I don't put any data on the line, then I can exit without any problems.

Does this sound like a UART configuration problem or a Keil issue. I though it might be that Keil was still trying to cope with the streaming data coming in, causing some sort of overflow and not being able to exit. I'm still evaluating Keil and being able to map COM1 to Keil is a feature that I really need. Can anyone help? Thanks

Parents
  • Well, after installing the RealView tools with a ULINK pod, my PC still locks up while running the debugger. The most common error message the IDE gives me is "USB communication failure". When this happens on my 2.8 GHz Pentium 4 WinXP Pro machine with 256 MB of RAM, the most common way I have to recover is to hold the power switch for several seconds till it forces my PC to turn off. No other CTRL-ALT-DEL, end task, shutdown, etc. method hardly ever seems to work.

Reply
  • Well, after installing the RealView tools with a ULINK pod, my PC still locks up while running the debugger. The most common error message the IDE gives me is "USB communication failure". When this happens on my 2.8 GHz Pentium 4 WinXP Pro machine with 256 MB of RAM, the most common way I have to recover is to hold the power switch for several seconds till it forces my PC to turn off. No other CTRL-ALT-DEL, end task, shutdown, etc. method hardly ever seems to work.

Children
  • Sounds like a power problem on the target hardware. Does it help to plug/unplug ULINK?

  • This is a completely differernt issue now. Before, it was a simulation problem and now ULINK seems to cause a problem.
    When exactly does uVision with ULINK lock up?
    When it locks up, you should disconnect ULINK from the USB interface rather than switching off the power of your PC. This helps in almost all cases.
    In order to find this problem, we need to know what target hardware you are using and we probably also need your application. You should send this information to support.intl@keil.com.

  • So far, with the RealView tools, the lockup has occurred while the debugger was just running with no breakpoints set, no manual halts done, with code running from flash ROM.

    I haven't tried to fix the problem by unplugging the ULINK and plugging it back in again using the RealView tools. That never seemed to help with the PK-ARM tools. Next time it freezes I'll try unplugging the ULINK and plugging it back in and let you know what happens.

    I usually have to force my PC's power supply to turn off because when this problem occurs, the PC is usually not able to close the IDE and recover. The IDE application can't be 'ended', and a shutdown won't shutdown the PC. Occasionally the mouse and keyboard would appear to be frozen too.

    For whatever it's worth, my board uses an ATMEL AT91SAM7S32, and MCK is ~ 54.9 MHz (20 MHz crystal, MUL = 1401, DIV = 255).

  • To check for a target power supply issue, I'll tweak the project so it runs on ATMEL's SAM7S64-EK eval board and see if the problem shows up there too. Might take me a day or two to get around to that. Stay tuned...

  • Temporarily unplugging the ULINK pod did allow me to recover without having to cycle power on my PC. However, when I plugged the ULINK back in Windows said it had to close the offending app (uVision IDE).

    When I restarted the uVision IDE and tried to start the debugger, it repeatedly complained that no ULINK device could be found, even after I temporarily unplugged it again several times. Once I cycled power on my target, then the debugger was able to be started again.