RL-Flash and RTX problem

In my project I want use the fopen, fwrite, fclose functions within an USB interrupt

you cannot do that! this is the cause of your exceptions. do it in the main loop / task context.

do you really believe it is a good idea to block the entire system (excluding FIQ) while you write to non-volatile/RAM drive storage while at interrupt mode?

I use this function in the IRQ because I have to know if th operation is succesfully completed to send the result to the host.

Moreover the MCB2300/usbmem example do the same thing.

And why without the RTX it works ? It's my question

Thanks

you are not allowed to use these functions while at any mode other than user mode. it is as simple as that - FlashFS rules.

Moreover the MCB2300/usbmem example do the same thing.

interesting. are you sure it is a genuine Keil example? that would surprise the hell out of me.

use an interaction between a task/main loop to get the work done.

you are not allowed to use these functions while at any mode other than user mode. it is as simple as that - FlashFS rules.

Ok I understand but why it works perfectly without the RTX ?

why it works perfectly without the RTX

I really don't know the answer to that.

"it is as simple as that - FlashFS rules."

Yes, it is always wise to adhere to the rules laid down in the documentation.

Yes, it is always wise to adhere to the rules laid down in the documentation.

you see? there is hope for me. I only break RTX rules :-)

I don't see this rule in the documentation

"I only break RTX rules :-)"

Well that's all right then ;)

where I can find this rule in the documentation.

Another think, why if I increase the OS_TICK in the RTX_Config.c, it works ?

Works, or seems to work?

In an incorrectly written application, a lot of the behaviour can change in strange ways when you increases or decreases the length of the timeslices.

But does that mean that changing the length of the timeslices is a correct way to solve a problem?

Of course no, but I try to understand

Some time-critical code doesn't work well with an RTOS because they don't expect someone else to jump in and steal the processor for them.

Changing the time slice length may make such code behave as if it works. It's like taking a drunk and have him walk on a narrow plank over a stream of water. The drunk will fall in. Make the plank a little bit wider and it will seem to work. But it will still just change the probabilities that the drunk will fall off. A better method would be to replace the plank with a bridge with railings. Or maybe have the drunk sober up before trying to cross the water stream.