Trying to install RLP interrupt on G400... With no luck

Ok, it’s no secret I want to handle CAN myself. After two wasted man-days, I’ll be happy to just see anyone installing any interrupt using G400 and RLPExt. Has anyone tried that or am I the first? I just can’t get it working.

So, here’s what I got. The native program:

#include "RLP.h"

void Handler(void * arg)
//Handles nothing
int InstallInterrupt(void *generalArray, void **args, unsigned int argsCount, unsigned int *argSize)
    //"18" is PWM IRQ for G400 and EINT for G120, but that matters not
    if (!RLPext->Interrupt.Install(18, Handler, ((void *)0)))
        return -1;
    return 1;
int RlpTest(void *generalArray, void **args, unsigned int argsCount, unsigned int *argSize)
    return 12;

The managed program:

private static RLP.Procedure _rlpTestFunction;
        private static RLP.Procedure _rlpInstallFunction;
        public static void Main() {

            //Loading RLP
            var gaga = Resources.GetBytes(Resources.BinaryResources.G400Rlp);

            _rlpTestFunction = RLP.GetProcedure(gaga, "RlpTest");
            _rlpInstallFunction = RLP.GetProcedure(gaga, "InstallInterrupt");

            Debug.Print("So far so good");

            var gogo = _rlpTestFunction.InvokeEx(new byte[4], 12, 12, 12, 12, 12);

            Debug.Print("We are still alive, test function returns " + gogo);

            var gugu = _rlpInstallFunction.InvokeEx(new byte[4]);

            Debug.Print("G400 is dead already, this print never happens.");

            while (true) {


Invoking “RlpTest” works fine, it returns 12, as expected (so I assume the compile compiles correctly). Invoking “InstallInterrupt” crashes G400 immediately, no matter what I try.

Am I missing something? Maybe it’s just some compiler settings I forgot to set?..

P.S. I’m using emIDE and gcc.

Now, if I run the[em] exactly the same[/em] program on G120 (of course, after editing memory regions and setting mcpu to arm7tdmi), it works just fine. InstallInterrupts returns 1.

@ Simon from Vilnius -

What problem with CAN now? or just want to handle CAN by yourself?

Yes, I just want to handle it myself, but cannot install interrupt.

Ummm… Guys?..


@ Simon from Vilnius -

we will take a look when we have time, but any suggestion you you guys are welcome!

On what timeframe your “when we have time” is?.. I’m afraid I need this a little bit sooner :frowning:

I must agree with Simon when a product is on “production stage” and it’s “premium” then as a customer we should be able to expect the documented functionality to work and not that the customer has to suggest a solution for functionality that’s not working as expected.

We always do our best. We understand your need and this is on the list to be looked at. As of today, we are very busy with 4.3 which effects most if not all customers.

Remember that this feature maybe working fine. We also have consulting services to handle most needs quickly.

That totally freaks me out. Transition from 4.1 to 4.2 was very painful, and EMX->G400 was (and still is) even worse…

And here comes 4.3.

Do not worry. We are planning a very smooth transition.

Note that it also included updates to CAN so this maybe good for you, but it is going to be a while before it is out of beta.

Alright guys, so when could I expect some progress on this issue?

I did some more digging… Actually, even the (presumably) trivial function

effectively crashes the G400. 

Shouldn't it just read some register and return the value? If so, the only reason G400 dies I can think of is bad linking. Like, for example, RLP region doesn't actually start at 0xA0000000...

@ Simon from Vilnius -

Could you please add simple code (C# and native RLP) then we just copy and re-compile them, it will be faster than we start from scratch.

Thanks a lot

See it at the first post :))

@ Dat - sweet Dat, can’t wait to see your results…

it should work with these value
#define RLP_ADDRESS (0xA0000000)
#define RLP_SIZE (0x17FFFFC)

Thanks for your feedbacks

It was 0x17FFFF8 before, right? Unfortunately, I cannot check that now, but if so, then this is going to be the most expensive 4 bytes in my career :slight_smile:

@ Simon from Vilnius -

We understand, let us know if you need anything else!