CrossWorks for ARM Olimex ARM-USB-TINY-H Debug verify failed

Follow

B. Seiler

• April 01, 2011 07:14

I try to use ARM USB-TINY-H with CrossStudio V2.0.8 and up.

Can download my project once without any erros, but when i start to debug, i get the common error "Debug handler verify failed".

I use a ARM USB-TINY-H without any problems on with V2.0.8.

With the older CrossWorks V1.7 the TINY-H and TINY work both without any problems - on the same computer.

Any idea, where the problem may be?

 

Regards

Björn.

0

• 

  Jon Elliott

  • April 01, 2011 10:36

  It is most likely that the JTAG clock frequency is too fast - V2.x is able to clock the ARM USB-TINY-H 5 times quicker than V1.x because it knows about FT2232H devices. Try reducing the JTAG clock frequency by increasing the JTAG clock divider target property.

  0

  Comment actions Permalink
• 

  B. Seiler

  • April 01, 2011 11:17

  I tried it now with a JTAG Clock Divider = 100 and Adaptive Clocking On and Off also.

  The results are the same, i can download my code once, and the debugger (the cpu) jump to Disassembly Adr 0x04 -> undef_handler_c(). If i try to connect to my target again, without reconnect my JTAG device, i get the error "Cannot stop target". When i then click on reconnect on the Targets page, i get the same undef_handler.

  I also tried the Target Gerneric FT2232 Device" and the Olimex ARM-USB-TINY Target. Same result. On the Target property page, i can choose the "Device Driver", her is alswas FTDI selected, should i try the libUSB driver too?

  Thankyou for you answer!

  0

  Comment actions Permalink
• 

  Jon Elliott

  • April 01, 2011 11:38

  It doesn't sound like a device driver issue.

  What is the target device and the board you are using?

  If you use one of our example projects, do you get the same behaviour?

  Have you defined STARTUP_FROM_RESET?

  0

  Comment actions Permalink
• 

  B. Seiler

  • April 01, 2011 11:56

  Very interesting...

  We use an AT91SAM9263 CPU, the configuration is same as in the eval board from Atmel.

  I tried the example from the board "debugio"  and "drystone" and both work fine.

  We use our own Startup file, there's no STARTUP_FROM_RESET contained, so it is always starts up from reset.

  0

  Comment actions Permalink
• 

  B. Seiler

  • April 01, 2011 12:12

  So, i compared some project properties and find one option called: 

  "Debug Handler - Halt Mode", wich i can not see in my project but in the example project.

  (see attached file)

  What does this affect?

  0

  Comment actions Permalink
• 

  Jon Elliott

  • April 01, 2011 16:15

  This is a property group that is used to set other properties - when set to "Halt Mode" it will set the following properties:

  • "Target Control Options > Use Debug Handler" to "Yes"
  • "Target Control Options > Monitor Mode Debug" to "No"
  • "Target Control Options > Monitor Mode Memory" to "No"
  • "Target Control Options > Debug Handler Load Address" to "_vectors+0x10"

  0

  Comment actions Permalink

Please sign in to leave a comment.