Is there any way to use the Localfilesystem without it upsetting the interrupts ? I do not mind if accessing the local filesystem would be slow, just that interrupts are left alone.

Unlikely IMO, since LocalFilesystem relies on semihosting which means that on every filesystem call the core gets halted until the request is handled. Although... if you can make the debug trap to be the lowest priority, it's possible that it won't preempt other active interrupts.

In theory you could make a PC app that would listen to commands over serial from mbed and handle files over PC-side mass storage interface... not sure if this is worth the hassle.

Is there any information on the timing of this semihosting part, is it fixed amount of time per call or can it be variable ? How can I set the priority of the debug trap ?

My current project involves an mbed reacting to interrupts as close as 2.5 usec apart and it copes really well using a small bit of assembler. As soon as I try to access the Localfilesystem though it fails. Since I used up all port pins (except for the ethernet interface) I cannot use SD card storage or such unless I divert from the mbed to for example the LPCxpresso or even a custom built system with the LPC1768.

While I have implemented a JTAG debugger for older ARM7 based microcontrollers, I haven't implemented one for the newer Cortex-M parts so my thoughts below on the semihost stuff might be incorrect :)

I suspect that this can be slightly variable. Typically a JTAG device can't send an interrupt back to the host. The host (the special mbed interface chip in this case) needs to poll the device to see if it has halted due to something such as a semihost related breakpoint. Such polling would make it variable with a maximum latency occurring if you issue the semihost call immediately after the previous poll attempt and need to wait for the next poll. There would also be variability in the time it takes to read/write the memory of the LPC device and the FLASH storage for each individual request.

I don't think the priority level of the debug monitor exception handler matters that much when you are using the JTAG based halting mode as you would be using in the case of the LocalFileSystem. I have disabled the halting JTAG debug mode on the mbed and installed a debug monitor exception handler for my MRI debugger and then the priority does matter and it can make debugging other ISRs at priority level 0 a royal pain.

I think the only easy solution to your problem is to use another storage solution like SD card. The only other solution I have come up with is when I only need a small amount of read-only storage. In that case I was able store the files in the left over 512K of FLASH on the LPC device itself.

If anyone knows a bit about the JTAG interface works on the Cortex-M devices then I do have some questions related to how it works and whether there might be another way to implement LocalFileSystem which wouldn't have such a big impact on the code running on the device. I thought that the JTAG host could read and write to the memory on the LPC17xx while the device is still running (part of the non-invasive support on the Cortex-M3 parts.) If it could do this then maybe the LocalFileSystem could just use a breakpoint once from the constructor of the LocalFileSystem object to tell the interface chip about the location in memory where a command buffer was located. This buffer would have a format something like:

struct LocalFileSystemCommandBuffer
{
    volatile unsigned int opCode;
    volatile unsigned int operand1;
    volatile unsigned int operand2;
    volatile unsigned int operand3;
    volatile int          returnValue;
};

When the LocalFileSystem wanted to do something like open the file, it would fill in the operand* fields of this structure and then set the opCode field to a non-zero value which indicates a file open request. The LocalFileSystem function would then enter a loop waiting for the opCode field to be cleared to 0. The interface chip could periodically poll the contents of the opCode field in this structure and when non-0, it would process the specified command (reading and writing from memory referenced by addresses stored in the operand* fields as necessary) and then clear the opCode field when done so that the LocalFileSystem code would know that the operation had been completed and that it could continue.

Of course that would only work if the interface chip is able to use the JTAG interface to read/write to the device's memory when the device itself isn't in the halted state.