Main Site Documentation

Fez Panda II and JTAG


#1

So I just ordered a Fez Panda II for the purpose of experimenting with compiling native code and using the JTAG interface. I do realize I need to wipe the original firmware, but that is fine and I assume I can restore the original firmware after I’m done?

However I’m a bit confused by the exposed JTAG interface on the Panada II. From the pictures, it looks like it is an 8-pin connector, not 10-pin. What would I need to do to connect this to a JTAG adapter? Is there some documentation somewhere that explains this?


#2

The firmware running on FEZ Panda is propitiatory and so you can’t restore once removed. But why erase it? You can load native code on FEZ Panda, see RLP in documentation http://www.ghielectronics.com/downloads/NETMF/Library%20Documentation/Index.html
You will see a lot more features built into the firmware that will be very useful no mater what your application is.

For the connector, there is no room to add a standard 10pin connector so we used a smaller one. You will need to rewire it. The schematics (and EAGLE design files) show the pinout.


#3

Once you erase the panda there is no going back…


#4

Is not?


#5

@ Mike funny! where did the NOT come from? I foxed it, thanks


#6

For this particular project I really do need to erase the firmware. I’m working on a .Net-> ARM assembly compiler that generates a native application from an existing .Net exe. This includes a native runtime and your own application code compiled down to ARM assembly.

OK it is fine if I can’t restore the original .Net firmware (I can order a second Panda II for .Net development), but the question is still how do I interface with the exposed JTAG pins? It is advertised as having JTAG support, after all.


#7

I’m pretty sure there’s a lot of people that would be mighty interested in a project like that.


#8

Like I said, the schematics shows the connections of the pins on the board http://www.ghielectronics.com/downloads/FEZ/Panda_II/FEZ_Panda_II_sch.pdf
Wire those to a 2x10 0.1" header with standard JTAG pins and then you can connect any standard JTAG.

If you do not know the standard pinout then see EMX Dev Sys schematics http://www.ghielectronics.com/downloads/EMX/EMX_DevSys_sch.pdf

What you are doing is very cool but why not take the NETMF source code and start from there and add a JIT? Actually JIT is in there but was never completed.


#9

I think the main problem with JIT on a microcontroller is the limited memory space. A JIT compiler is quite complex and it outputs a new binary that itself needs more space. This was the original idea I had but I think the memory limitation is a real problem.

Right now the compiler generates C++ code that can be compiled for x86, and the runtime it generates supports multithreading, GC, delegates, boxing/unboxing, generics, arrays, etc. My plan is now to change it so that it generates ARM assembly directly.


#10

Still, take the files generated by NETMF and use those to recompile to ARM.

NETMF = .NET and use the same compiler but the assemblies it starts with are simpler = your work is simpler


#11

Actually, now that I think about it…

Maybe a slightly different approach is to use the Panda II in its original form and then use RLP as a temporary test mechanism for my compiled runtime/application.

But this would only work if I can debug the native code. Is this possible by using a Panda II with its original firmware? Or at least, how are other people debugging their RLP code?


#12

When you write RLP code, you are usually writing simple drivers that do not need intensive debugging. The rest of the code is all C#. So, debugging can be done through sending serial messages or using IOs.


#13

Gus,

My compiler currently does a static code path analysis and strips out everything your application doesn’t touch (types, strings, resources, methods etc). Whether this is from a .Net CF of full .Net application is somewhat irrelevant since it only compiles what you actually use (if you use DateTime, but never call Format, the Format code is never compiled). As such it can create code that is even smaller than the .Net CF + your application, even if it starts from a full .Net application exe.


#14

OK so using RLP might not be the best approach since I would definitely need to do some intensive debugging.

I’m hoping I can set up an ARM emulator so that I don’t even need to deal with JTAG etc. Has anyone tried OVP? Any other suggestions for a good emulator?


#15

@ Gus -

Greetings,

I have been handed a legacy project based on a FEZ Panda II and I am currently getting up to speed with NETMF and the hardware. One of the issues is going to be performance of some simple DSP so I am interested both in running native code under NETMF and the alternative of running a much simpler system on the unit, i.e. erasing a unit and downloading native code to a board. This led me to a topic from 2 years ago quoted below…

The link to the document is now broken and I have had no luck - probably due to ineptness - in finding it via a search. Can you help please? (UPDATE I have since found this - my mistake was to search for a PDF.)

Secondly can you quickly point me at a document that shows me how to completely erase the board so I can use the JTAG interface. I have successfully updated via the Tiny Bootloader but I did not see any way to remove the bootloader and hence, presumably, the start up code used to disable JTAG access.

Apologies for this detour into ancient history.

Many thanks,

George Sealy

[quote=“Gus”]
The firmware running on FEZ Panda is propitiatory and so you can’t restore once removed. But why erase it? You can load native code on FEZ Panda, see RLP in documentation http://www.ghielectronics.com/downloads/NETMF/Library%20Documentation/Index.html


#16

The Usbizi chip on the panda 2 can be erased but you will not be able to restore the original bootloader after.

You could use a second Panda or other to write and debug the native code and then convert to RLP for NETMF on the first board.

Secondly since the Panda is now legacy you can look at a Cerbuino and utlize the opensource code to tweak as needed. The F4 chips have FPU and are better for DSP.

The cost of the Cerbuino should be small when compared to the engineering hour cost.

Just my .02 cents.