FEZ Hydra hanging in RLP for ~4.5 microsecond

As I mentioned before in some other thread, I’m implementing I2C slave device which would support multiple addresses (need to emulate multiple I2C slaves in one device).
.NET is not an option for this as I need to support 400Khz I2C speed and using bitbanging, so I’m running I2C slave emulation in RLP.

Everything is working and the protocol is running but once in 5-15 minutes I see that Hydra is stuck for about 4.5 microsecond. As a result, I’m missing clock tick and losing sync with the master.

It looks like it’s stuck mostly on command


My init is

AT91C_BASE_PIOD->PIO_ODR= 0xFFFFFFFF;		//disables output on all lines
AT91C_BASE_PIOD->PIO_MDER= CLOCK | DATA;	//enable Multi-driver
AT91C_BASE_PIOD->PIO_PUDR= CLOCK | DATA;	//disable Pull-up
AT91C_BASE_PIOD->PIO_IFER = CLOCK | DATA;	//enables input filtering on clock and data

Anyone have some idea, what’s wrong? I saw it on 3 different devices, so I guess it’s not malfunctioning device.

I wonder if GC kicks in at that time.

I wonder what is GC? :slight_smile:
How can I see if it kicks in?

GC (Garbage collector of NETMF framework) will not kick in, as you’re running RLP code, which freezes NETMF.

But there can be higher level interrupts that interrupt your wait loop. F.e. ethernet, USB or DMA controller for LCD update, etc… Maybe you should search for a way to disable and re-enable interrupts using assembly code.

Check this out: Documentation – Arm Developer

Oh, yeah now I get it :smiley: GC = Garbage collector. It’s definitely not it, as there’s no .NET while in RLP, as WouterH kindly explained, and no GC in pure C of RLP. Hope it’s not some timer that lets .NET back in after some time.

About interrupts - is there some way to check out, which interrupts are set? I’m not setting any interrupts while in C (you can see my whole init and no other CPU settings done) and .NET code at the beginning is very simple too but I’ll recheck it.

Anyways, thanks for the idea, I’ll take a closer look at the interrupts now.

One more thing I thought about is Power Management. Is it possible that there’s some power management set by default (for example in boot loader), which leads to such behavior?

I bet what you’re seeing is interrupts from other peripherals interrupting your code. Note that RLP is a hack to load ELF files at runtime. The main purpose of the FEZ Hydra is running NETMF. So when you start the board, NETMF will start and install interrupt handlers, there’s nothing you can do about that :slight_smile:

But you can dump the interrupt mask registers of different peripherals to determine which interrupts are used by NETMF.

There’s no way to just clear those interrupts?

Currently I’m doing some workaround to solve this issue in my code (resetting hanged transactions). But I have some interesting idea - I’m planning to remove NETMF from the flash and flashing RTX OS provided by Keil. I guess it will give my better control and will provide multitasking for other projects I’m planning for Hydra.
Anyone ever tried that RTX on Hydra or any other devices? How hard it is? I mean the coding part, HW reworks for the flash and flashing will not be a problem.

Of course, if you’ll only use C in your project, then wipe off the NETMF framework and attach your JTAG debugger :wink:

@ WouterH -

hello WouterH, can you see my post http://www.tinyclr.com/forum/topic?id=9905 ?

Well, for the I2C slave I will use only the C, but I need Ethernet at the beginning in order to send the data I want the slave to answer. If I’ll be able to use that ethernet port for Hydra in C, then I’m OK.
One more question - if I whipe the NETMF, should I write some kind of bootloader or I just can put a file in some fprmat with aome name and it will be able to run? Is there some “How to” for such thing?

You might also consider running Linux.