LPC1768, hard fault when calling fopen() after Ethernet connect

[janjongboom]

Description of defect

I am seeing a hard fault when calling fopen() after Ethernet connect.

Expected behavior

Calling fopen() after calling connect on the ethernet interface does not throw an error.

Actual behavior

It hard faults.

Target(s) affected by this defect ?

LPC1768

Toolchain(s) (name and version) displaying this defect ?

ARM

What version of Mbed-os are you using (tag or sha) ?

mbed-os-5.4.0

What version(s) of tools are you using. List all that apply (E.g. mbed-cli)

n/a

How is this defect reproduced ?

Example program is here https://os.mbed.com/questions/80658/HardFault-occurs-when-fopen-is-called-af/

User verified working behavior on Mbed 2 and Mbed OS 5.3; broken behavior on 5.4 and 5.8.

[0xc0170]

@kjbracey-arm @mikaleppanen Please review
[Mirrored to Jira]

[kjbracey]

I'm reckoning the exception is happening as __semihost(SYS_OPEN, args) is called from semihost_open (R0=1=SYS_OPEN, R1=current thread stack pointer).

HFSR (Hard Fault Status Register) has bit 31 set - DEBUGEVT. The BKPT 0xAB instruction that's supposed to be captured by the debugger for semihosting hasn't been, so it just generates a hard fault.

Somehow starting the Ethernet has stopped the semihosting from working - deactivated the debug connection or made it lose sync?

Now, I know nothing much about the semihosting implementation - I suggest referring this to someone who knows how that's supposed to work, and what could interfere with it.

Maybe someone who can reproduce it could try a git bisect on mbed OS - might be the fastest way to isolate. I can't obviously see anything touching LPC1768 Ethernet or debug/semihosting in between 5.3 and 5.4.

[Mirrored to Jira]

[kjbracey]

Looks like it's nothing to do with the Ethernet - same basic effect can be triggered much more simply as shown in #6624.
[Mirrored to Jira]

[maclobdell]

cc @mmahadevan108
[Mirrored to Jira]

[Nuclearfossil]

Is this actually resolved? I'm seeing this exact issue when sending code to an FPGA across the SPI.

I'm migrating code from OS 2 to 5.13 and I'm seeing hard faults whenever I inject a wait_ms.

For example:

void customFPGALoader()
{
    SPI spi(p5, p6, p7);
    DigitalOut cs(p8)
    , led1(LED1)
    , led2(LED2)
    , led3(LED3)
    , led4(LED4)
    , spi_en(p17);

    LocalFileSystem local("local");

    led1 = 1;
    cs = 0;
    spi.format(8);
    spi.frequency(1000000);

    spi_en = 1;
    wait_ms(50);

    const uint32_t FPGAMAXIMAGE = 40000;
    FILE* pfp = fopen("/local/FPGA.img", "rb");

    if(pfp != nullptr)
    {
        for(uint32_t i = 0; i < FPGAMAXIMAGE && feof(pfp); i++)
        {
            spi.write(fgetc(pfp));
        }
        fclose(pfp);

        for(uint32_t i = 0; i < 10;i++)
        {
            spi.write(0xFF);
        }
    }

    cs = 1;
    spi.frequency(10000000);
    spi_en = 1;
    led2 = 1;
}

[kjbracey]

I've not heard of any progress.

Since this issue was filed, I've become a bit more familiar with the LocalFileSystem stuff - used it on non-LPC1768 devices to get semihosted console, as seen now in an example here: https://os.mbed.com/docs/mbed-os/v5.13/apis/filehandle.html.

Looking at the LPC1768 sleep implementation, we see this:

mbed-os/targets/TARGET_NXP/TARGET_LPC176X/sleep.c

Lines 27 to 32 in b82cfcc

	void hal_sleep(void) {
	#if (DEVICE_SEMIHOST == 1)
	// ensure debug is disconnected
	mbed_interface_disconnect();
	#endif

That's what causes the issue - the moment the device sleeps (because of the wait_ms), the debug connection that LocalFileSystem for its semihosting calls is using is dropped.

The behaviour is explicitly documented:

mbed-os/targets/TARGET_NXP/TARGET_LPC176X/sleep.c

Lines 21 to 24 in b82cfcc

	* @note
	* The mbed interface semihosting is disconnected as part of going to sleep, and can not be restored.
	* Flash re-programming and the USB serial port will remain active, but the mbed program will no longer be
	* able to access the LocalFileSystem

Comments elsewhere in that file suggest that the LPC1768 actually has issues with losing debug in deep sleep (as do most devices), so I wonder whether the disconnect is really necessary for a normal sleep.

The usual setup in other devices is that hal_sleep does not disrupt the debug port, and hal_deepsleep does.

A debug profile build globally stops the sleep manager from ever using hal_deepsleep, avoiding debug problems.

Maybe LocalFileSystem itself should be locking deep sleep while active, but it doesn't. But in LPC1768's case, both sleep implementations are the same anyway.

It would be good if someone at @ARMmbed/team-nxp could look at this.

In the meantime, maybe you could just experiment and take out that disconnect call? Have a look at LPC1768 documentation for hints about the way the sleeps should be working?

[Nuclearfossil]

Hey Kevin,

Thanks for the feedback and heads up.

Interesting - I noticed that there's no 'profile' setting in the online compiler (that I could see) for picking release/developer/debug. So that could be the overall issue in my case; online compiled versions of the codebase did not hardfault, whereas mbed studio compiled versions did.

I may just see about doing a developer/release build and see if the issue persists.

I'm hesitant on removing the wait_ms calls in the original codebase as I'm not sure what the intent was (original developer has left, no documentation, the standard story on this stuff).

Again, thanks.

[ciarmcom]

@janjongboom thank you for raising this issue.Please take a look at the following comments:

Could you add some more detail to the description? A good description should be at least 25 words.
What target(s) are you using?
What toolchain(s) are you using?
What version of Mbed OS are you using (tag or sha)?
It would help if you could also specify the versions of any tools you are using?
How can we reproduce your issue?

NOTE: If there are fields which are not applicable then please just add 'n/a' or 'None'.This indicates to us that at least all the fields have been considered.
Please update the issue header with the missing information, the issue will not be mirroredto our internal defect tracking system or investigated until this has been fully resolved.

[adbridge]

We've updated our automation, I will fix the requirements .

[ciarmcom]

Thank you for raising this detailed GitHub issue. I am now notifying our internal issue triagers.
Internal Jira reference: https://jira.arm.com/browse/IOTOSM-2456

[ciarmcom]

We closed this issue because it has been inactive for quite some time and we believe it to be low priority. If you think that the priority should be higher, then please reopen with your justification for increasing the priority.

[defcon8]

We face the exact same issue. Accessing mbed (5.15.5) LocalFileSystem after SPI bus communication took place, results in a crash / hardfault.

Any update on this issue? We need to be able to write some settings to the flash rom after SPI is initialised.

[0xc0170]

I haven't seen any update related to the problem.

@ARMmbed/team-nxp would you be able to help?

@defcon8 the reply from Kevin above provides good details related to sleep and wait_ms. Or just use storage instead of localfilesystem?