FreeRTOS Privileged_Function

[Matt-]

My project involves generating C code for the Crazyflie, from another language Whiley.

I have come across the use of PRIVILEGED_FUNCTION in FreeRTOS, in particular the task.h file and I am in the process of reading up on it and experimenting to see if removing it makes a difference to the Crazyflie. It is important because my generated C code will replace stabilize.c. As part of this process native methods need to be declared that emulates method signatures in task.h, for example xTaskGenericCreate and vTaskDelayUntil.

I have a couple of questions I am hoping to get an experienced perspective on.
So far commenting out this tag does not appear to make any difference to the Crazyflie's ability to function. I am picking that indicates there is no likely negative side effects from adopting this approach. Is this assumption safe?

This one is perhaps a little more fundamental. The tag only seems to appear (be required?) in method declarations, for example appearing in task.h but not in task.c where the method is implemented, nor in stabilize.h where the method is called. Having figured out roughly what this tag is, I may be over-thinking this. I am replacing stabilize.c with code that complies with task.h signatures, I am starting to think I can safely ignore the tags presence in task.h. Is this safe?

An experienced opinion would be very much appreciated.
Cheers
Matt

[tobias]

From my knowledge the PRIVILEGED_FUNCTION is only used when you use the memory protection unit (MPU) functionality which we do not use. The PRIVILEGED_FUNCTION is then defined to nothing.

When it is defined it will place the functions in the privileged section in memory so they get the correct memory access rights.

You seem to be doing something interesting, want to share?

[Matt-]

I am doing an engineering honours project at Victoria University in Wellington, New Zealand. My supervisor, Dr Pearce, has developed a verifying compiler, Whiley. http://whiley.org/ In a nutshell Whiley enables an engineer to write code verification (pre/post conditions, loop invarients, etc) as you write code, which is particularly useful for proving the soundness of safety critical systems. Obviously embedded systems account for a lot of of our safety systems.

My project is to apply Whiley for the first time to an embedded system. By taking the Crazyflie and replacing C modules with C code generated by my custom Whiley to C compiler, then test its performance to see what differences there might be. Hopefully they will be similar, but the really interesting stuff is the process involved and the work-arounds needed. No doubt Dr Pearce will use the results to make Whiley more compatible with embedded system coding.

I have just finished the stabilize.c file, with all the hover mode stuff removed. Its taken a week to write in Whiley and then work through the compiler issues. Sadly I can't test it yet as last week I cooked the battery destroying the board... Expect an order for another Crazyflie to NZ shortly!

Once the replacement stabilize.c has been debugged (not looking forward to debugging on an embedded device...) I'll then look to replacing either the commander.c and/or controller.c files. Followed by adding the hover mode code back in.

All good fun

[tobias]

That sounds really interesting. A safety critical system will be very important for drones in the future. I can't say the Crayflie is, so your results will be really interesting for us if you would like to share.

Cooking the battery doesn't sound good, there is a protection circuit to prevent anything like that. How did that happen and maybe we can help out and fix it?

I would recommend to get a JTAG debugger if you don't already have one since it will help a lot when debugging.

[Matt-]

The Crazyflie was picked mostly because of the open source nature of the code and rtos, plus its a fun platform that hopefully will demo well. The project isn't to identify problems in Crazyflie code, nor to implement the verification stuff. It's to replace existing code with Whiley generated code and test to see if Whiley is as fast as C. Which I am picking it should be, as in essence my compiler is rewriting the Whiley implementation as a C file. Testing will give a definitive answer though Interestingly in an early presentation one of the attending lecturers made a bit of a fuss about ensuring the Whiley code reflects the existing C code, rather than any ability I might have to improve the code. Otherwise my abilities (or lack of) will distort the results.

I kinda assumed cooking the battery couldn't happen. I had been using it to test the stripped down stabilizer code, making sure I hadn't removed stuff I need. I plugged it back in for recharging (via the usb cable) and forgot about it for about three hours before I noticed the lights were no longer going. It was flying immediately before I plugged it in and spent that three hours by my elbow.

When I compared the battery to the replacement one I was given, it appeared puffed up and I was quite surprised how slim the fresh one is. Which may or may not be significant. The battery 'casing', I'm sure there is a better word, has a pin sized hole in it, there is some yellow staining on the adhesive pad near the hole (fluid, burn mark?) and the board under the hole is damaged (acid, heat?). The board damage is not large, I didn't notice it initially.

Current two theories are; the battery overheated or the battery received a knock on crash landing causing the pin hole. Our tech guy has it and I'm sure he would be happy to talk about it, just drop me an email or PM with a contact address to pass on.

I will Google the JTAG debugger, thanks for that.

[tobias]

Ahh OK, I think the result will be interesting anyway.

Thanks for the detailed battery explanation. We will do some further tests of the battery on our own. The battery should be able to handle puncture without "fire or explosion" and maybe it did but it doesn't sound good at all.

As for JTAG debugger we use olimex ARM-USB-TINY-H with adapter 20-10.

[Matt-]

Just picked up the new Crazyflie from our tech guy and quizzed him on the old Crazyflie's battery, asking if he found out what happened. He told me he looked at the battery under a microscope and best he can tell the battery didn't blow up or cook. He thinks the outer protective plastic was worn away or penetrated by pins on the board causing a short against the inner foil. Its done some internal damage resulting in leds not working as strongly as they should and he expressed surprise that the motors still work. I'm about to run the Crazyflie code through it, I'm an optimist...

He's also made a battery case on a 3d printer adding 2 grams. And he had to replace the on-off switch on the new Crazyflie as it was defective. Not a complaint, but thought you should know.