Small ARM7 with realtime debug memory access?

"Oliver Betz" skrev i meddelandet news: snipped-for-privacy@z1.oliverbetz.de...

The AVR32 based uC3000 series will support this.

"non-intrusive realtime memory access" in debug is quite a big ask. You'd need spare cycles to do this, and if that resource was spare the chip designers would have filled it with Application-useful functions.... I think freescale have something along these lines, but they may have the cycle space to do it. In theory, you could cycle share the memory, but that's going to push down the real-time speed, and so impact the operation anyway (so it is still intrusive, but less intrusive than am interrupt...) Why do you need 'non-intrusive realtime memory access' ?

-jg

Let's call it "nearly non intrusive" or "without ISR".

The HC12/9S12 has usually enough spare cycles. After a certain time, the BDM steals a cycle, but I don't think this happens in real applications very often.

But your post reminds me that I have to look at the Coldfire manuals whether there is still room for unnoticed access.

I have applications with _very_ tight timing of port signals and (therefore) long periods of disabled interrupts.

Oliver

Any more details Ulf ? Is this on registers only, on chip RAM memory, FLASH memory ?

- the debug core has to get a time-slice to access the memory, so does the AVR32 have such 'spare' time slots ?

-jg

The uC3000 has a bus matrix so if the CPU is not accessing a resource it is accessible to the debug unit. I do not know the exact details.

But the AVR32 isn't an ARM7 derivative, as requested by the OP, is it?

Peter

Hi Oliver, there are many devices in the NXP LPC2000 family with ETM (Embedded Trace Macrocell). This provides an option to trace the execution in realtime without any CPU participation / distraction. The side effect is that you need to use 10 pins of the device and you need a trace emulator. Lowest cost trace probably J-Trace from

Hi Oliver, there are many devices in the NXP LPC2000 family with ETM (Embedded Trace Macrocell). This provides an option to trace the execution in realtime without any CPU participation / distraction. The side effect is that you need to use 10 pins of the device and you need a trace emulator. Lowest cost trace probably J-Trace from

I don't konow the capabilities of the ETM, but "trace the execution" is different from "access memory".

Again: I mainly want to watch and edit variables while the program is running.

Oliver

Yes, but he asked for something which does not exist. The ARM JTAG will halt the CPU during accesses.

You mean that there are no ARM7 derivatives allowing background memory access? Paul Gotch mentioned "Coresight" last year, but I don't know whether it does what I mean.

Anyway, I'm 99% sure now to use a MCF5213 - not only for the debugging but also because it has a pretty fast A/D-Converter.

Oliver

What about trace instead? The NXP variants at least provide access to trace via the ETM. Not the same as being able to query a memory location directly but it may get you what you need and it doesn't stop the micro, unlike JTAG access.

Robert

Trace will not allow you to modify variables...

OK, I'll give it one more shot. Have a look here:

What you are looking for is called history. A bond out emulator were every bus, including the internal memory bus is accessible to an outside supervisor processor. This supervisor can watch all memories but as soon as you try to modify anything, you will interfere with real-time. This concept has two major disadvantages: Number one, it is too expensive, number two, it is too expensive ;-) actually number tow is that bond-out chips and production chips were always a little diffrerent, so sometimes you debugged the bondout for problems that your real device did not have and sometimes the bondout did not show the problem of your real device. It is a good thing that this is part of microcontroller history!

Robert

that's waht I meant by "As far as I see, they all need an interrupt routine to send information to the host".

No.

Read about the Freescale BDM in the HC(S)12 and the S08. It reads from target memory usually without any effect on the target. The Coldfire BDM also reads from a running target, but this causes a slight delay.

Certainly they let me also write to the target memory, but that's no more "non-intrusive" .

But it's a great tool during system test and optimization. I put many settings or status indicators in global variables during development and can test and tweak the system like I test and tweak hardware with a scope and trimpots on a breadboard.

Oliver