Using Studio 7.0.2542, adding action tracepoint causes code execution to change.

Go To Last Post
9 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Not certain if this is the correct forum.

Use----

Microchip Studio 7.0.2542

Processor ATmega 16

JTAGice mkii from 2009/2010 serial number 090000006B6C  firmware version 7.27

Application is a slave for 1-wire communications.  (small size and dedicated application)  based on TI SN1102023 slave simulation

 

I have already encountered where I have to cycle power to the JTAGice mkii & ATmega 16 to make certain older code breakpoint settings are purged.

I have not encountered the same purge problem when I change tracepoint settings. 

 

The issue I have is that if I use a tracepoint (for a text print) in code that samples the 1-wire levels the behavior of the code changes.

I have not confirmed the following - as an example if I use three tracepoint actions to track variables during execution; the JTAGice mkii tracepoint action cause other negative code effects.  I really want to use the tracepoint feature.

 

At the present time I do not see a way forward where I can use the JTAGice mkii tracepoint to finalize code updates.

 

The JTAGice mkii is 13 years old - does anyone know if hardware changes since 2009 may cause problems?

Is firmware version 7.27 the most recent?  Could not find any details of firmware version on Microchip website.

 

Appreciate any feedback.

Thanks
Jim

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Luecke_now wrote:
the JTAGice mkii tracepoint action cause other negative code effects. 

Such as ???

 

If it is a delay on hitting the breakpoint then you're stuck. Any processor halting is going to affect timing.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thanks

Hard code breakpoint causes timing changes.

I really don't want to use code breakpoint unless it is at the end of processing within code area under investigation at which time timing .

I can live with this, but the real negative is that I need intermediate feedback during operations and I was lead to believe that the action tracepoint was the solution.  Tracepoint also has negative impact on timing.

 

Therefore I need to come up with debugging approach that doesn't really take advantage of Microchip Studio/JTAGice mkii.

 

Is this correct?

thanks

Jim

Thanks
Jim

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For code block timing, it is common to add a debug signal on an unused pin. Set the output state when you start the block and clear it when you leave. The iogic analyzer or oscilloscope is your friend. If you do it correctly, each pin change only costs you a few clock cycles (one on new Tiny1/0 or Mega0).

 

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0


Luecke_now wrote:
I need intermediate feedback during operations
OCDR "may" have low enough latency.

 

Luecke_now wrote:

Therefore I need to come up with debugging approach that doesn't really take advantage of Microchip Studio/JTAGice mkii.

 

Is this correct?

Usually yes

 


Atmel-8154-8-bit-ATmega16A_Datasheet

[page 218]

23.9.1 OCDR – On-chip Debug Register

The OCDR Register provides a communication channel from the running program in the microcontroller to the debugger. The CPU can transfer a byte to the debugger by writing to this location. At the same time, an Internal Flag; I/O Debug Register Dirty – IDRD – is set to indicate to the debugger that the register has been written. When the CPU reads the OCDR Register the 7 LSB will be from the OCDR Register, while the MSB is the IDRD bit. The debugger clears the IDRD bit when it has read the information.

...

Atmel megaAVR OCD (JTAG) | AVR JTAGICE mkII

[bottom]

IDR events

When the application program writes a byte of data to the OCDR register of the AVR device being debugged, the JTAGICE mkII reads this value out and displays it in the message window of the software front-end. The IDR registers is polled every 100ms, so writing to it at a higher frequency will NOT yield reliable results. When the AVR device loses power while it is being debugged, spurious IDR events may be reported. This happens because the JTAGICE mkII may still poll the device as the target voltage drops below the AVR’s minimum operating voltage.

OCDR read is twice as fast by Atmel-ICE.

megaAVR® Special Considerations | Atmel-ICE

[bottom]

IDR/OCDR Events

The IDR (In-out Data Register) is also known as the OCDR (On-Chip Debug Register) and is used extensively by the debugger to read and write information to the MCU when in Stopped mode during a debug session. When the application program in Run mode writes a byte of data to the OCDR register of the AVR device being debugged, the Atmel-ICE reads this value out and displays it in the message window of the software front-end. The OCDR register is polled every 50 ms, so writing to it at a higher frequency will NOT yield reliable results. When the AVR device loses power while being debugged, spurious OCDR events may be reported. This happens because the Atmel-ICE may still poll the device as the target voltage drops below the AVR’s minimum operating voltage.

IDR Events | Application Output | Trace | Microchip Studio

 

Troubleshooting real-time software issues using a logic analyzer - Embedded.com

[1/4 page]

The logic analyzer takes more setup time than print statements or a symbolic debugger, but the quality and quantity of the clues can be significantly better.

A value in a specific range can be caught by an assertion if willing to exit the program.

Adding Automatic Debugging to Firmware for Embedded Systems by Jack Ganssle

Generating Unique Error Codes | The Embedded Muse 306 by Jack Ganssle

More on Test | The Embedded Muse 361

 

 

"Dare to be naïve." - Buckminster Fuller

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

In the olden days we had phenomenally expensive in-circuit emulators that had instruction trace memory. That being a log of every single instruction as it was executed in real-time with data /I/O read & write operations also logged.

 

It took hours to decode but was sometime extremely useful.

 

You might choose to donate an entire 8-bit port to output your variables in real time, and use a logic analyser to decode/read them out.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

N.Winterbottom wrote:

It took hours to decode but was sometime extremely useful.

Indeed though today's PC/workstation/server has relatively enormous compute power to execute a simulator.

N.Winterbottom wrote:
... and use a logic analyser to decode/read them out.
A logic analyzer is likely extendable to add decoders.

 


ATICE30 (Wayback Machine)

 

AVR System emulator — QEMU documentation

[bottom]

  • Print out executed instructions (that have not been translated by the JIT compiler yet):

    qemu-system-avr -machine mega2560 -bios demo.elf -d in_asm

due to

QEMU AVR | AVR Freaks

 

Protocol decoder:numbers_and_state - sigrok

 

edit :

Simple Parallel Analyzer - User Guide - Saleae Support

GitHub - saleae/simple-parallel-analyzer: Saleae Simple Parallel Analyzer

 

"Dare to be naïve." - Buckminster Fuller

Last Edited: Tue. Aug 9, 2022 - 01:07 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

gchapman

Thank you very much for the details you supplied me

I have not decided how to move forward 

Thanks

Luecke_now

Thanks
Jim

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

I want to thank all AVR Freak users that replied to my post.

All the information is greatly appreciated.

Luecke_now

 

Thanks
Jim