Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LPC1768: Attaching callback with only one CAN interface defined causes hardfault #56

Closed
ral613 opened this issue Sep 6, 2013 · 2 comments

Comments

@ral613
Copy link

ral613 commented Sep 6, 2013

The Environment

  • Mbed LPC1768 on an Embedded Artists base board.
  • LPCXpresso v5.2.4 [Build 2122].
  • Using CAN2, LEDs and serial I/O interfaces.

The Problem

Hardfault interrupt on LPC1768 when attaching a callback function to a CAN object and only one CAN object is defined.

How to Reproduce

Run the following app on an mbed LPC1768 . Note the blue LEDs of death as HardFault_Handler() is called.

#include "mbed.h"

BusOut myleds(LED1, LED2, LED3, LED4);
CAN can2(p30, p29);
bool got_message = false;

extern "C" void HardFault_Handler ()
{
    error("Hit HardFault handler!\r\n");
}

void can_callback()
{
    got_message = true;
}

int main()
{
    CANMessage msg;

    printf("main()\n");
    can2.attach(can_callback, CAN::RxIrq);
    int i = 0;
    while(1) {
        printf("loop()\n");
        if (got_message)
        {
            got_message = false;
            can2.read(msg);
            printf("Message received: %d\n", msg.data[0]);
        }
        wait(0.2);
        myleds = i++;
        i %= 16;
    }
}

The Workaround

Create a second unused CAN object

CAN can1(p9, p10);

and run the app again. The app now works OK.

The Cause

Checking IER on both CAN peripheral modules when only one of them is enabled causes a hard fault.

The error is in function can_irq_set(), at line 167 of file …/mbed/targets/hal/TARGET_NXP/TARGET_LPC176x/can_api.c.

@mbednotifications
Copy link

I assume that this can be fixed by first checking if the CAN peripheral is
active,

Something similar is happening here:
// Have to check that the CAN block is active before reading the Interrupt
// Control Register, or the mbed hangs
void can_irq_n() {
uint32_t icr;

if(LPC_SC->PCONP & (1 << 13)) {
    icr = LPC_CAN1->ICR & 0x1FF;
    can_irq(icr, 0);
}

if(LPC_SC->PCONP & (1 << 14)) {
    icr = LPC_CAN2->ICR & 0x1FF;
    can_irq(icr, 1);
}

}

I don't have the hardware available now but I could look at it later this
week if nobody cares to beat me to it.

On Friday, September 6, 2013 11:55:20 AM UTC-7, Richard Low wrote:

The Environment

  • Mbed LPC1768 on an Embedded Artists base board.
  • LPCXpresso v5.2.4 [Build 2122].
  • Using CAN2, LEDs and serial I/O interfaces.

The Problem

Hardfault interrupt on LPC1768 when attaching a callback function to a CAN
object and only one CAN object is defined.
How to Reproduce

Run the following app on an mbed LPC1768 . Note the blue LEDs of death as
HardFault_Handler() is called.

#include "mbed.h"

BusOut myleds(LED1, LED2, LED3, LED4);
CAN can2(p30, p29);
bool got_message = false;

extern "C" void HardFault_Handler ()
{
error("Hit HardFault handler!\r\n");
}

void can_callback()
{
got_message = true;
}

int main()
{
CANMessage msg;

printf("main()\n");
can2.attach(can_callback, CAN::RxIrq);
int i = 0;
while(1) {
    printf("loop()\n");
    if (got_message)
    {
        got_message = false;
        can2.read(msg);
        printf("Message received: %d\n", msg.data[0]);
    }
    wait(0.2);
    myleds = i++;
    i %= 16;
}

}

The Workaround

Create a second unused CAN object

CAN can1(p9, p10);

and run the app again. The app now works OK.
The Cause

Checking IER on both CAN peripheral modules when only one of them is
enabled causes a hard fault.

The error is in function can_irq_set(), at line 167 of file
…/mbed/targets/hal/TARGET_NXP/TARGET_LPC176x/can_api.chttps://github.com/mbedmicro/mbed/blob/master/libraries/mbed/targets/hal/TARGET_NXP/TARGET_LPC176X/can_api.c
.


Reply to this email directly or view it on GitHubhttps://github.com//issues/56
.

@mbednotifications
Copy link

Fixed and verified that it works by modifying the 'can_interrupt' testcase.
#63

On Sunday, September 8, 2013 7:15:23 PM UTC-7, Joris wrote:

I assume that this can be fixed by first checking if the CAN peripheral is
active,

Something similar is happening here:
// Have to check that the CAN block is active before reading the Interrupt
// Control Register, or the mbed hangs
void can_irq_n() {
uint32_t icr;

if(LPC_SC->PCONP & (1 << 13)) {
    icr = LPC_CAN1->ICR & 0x1FF;
    can_irq(icr, 0);
}

if(LPC_SC->PCONP & (1 << 14)) {
    icr = LPC_CAN2->ICR & 0x1FF;
    can_irq(icr, 1);
}

}

I don't have the hardware available now but I could look at it later this
week if nobody cares to beat me to it.

On Friday, September 6, 2013 11:55:20 AM UTC-7, Richard Low wrote:

The Environment

  • Mbed LPC1768 on an Embedded Artists base board.
  • LPCXpresso v5.2.4 [Build 2122].
  • Using CAN2, LEDs and serial I/O interfaces.

The Problem

Hardfault interrupt on LPC1768 when attaching a callback function to a
CAN object and only one CAN object is defined.
How to Reproduce

Run the following app on an mbed LPC1768 . Note the blue LEDs of death as
HardFault_Handler() is called.

#include "mbed.h"

BusOut myleds(LED1, LED2, LED3, LED4);
CAN can2(p30, p29);
bool got_message = false;

extern "C" void HardFault_Handler ()
{
error("Hit HardFault handler!\r\n");
}

void can_callback()
{
got_message = true;
}

int main()
{
CANMessage msg;

printf("main()\n");
can2.attach(can_callback, CAN::RxIrq);
int i = 0;
while(1) {
    printf("loop()\n");
    if (got_message)
    {
        got_message = false;
        can2.read(msg);
        printf("Message received: %d\n", msg.data[0]);
    }
    wait(0.2);
    myleds = i++;
    i %= 16;
}

}

The Workaround

Create a second unused CAN object

CAN can1(p9, p10);

and run the app again. The app now works OK.
The Cause

Checking IER on both CAN peripheral modules when only one of them is
enabled causes a hard fault.

The error is in function can_irq_set(), at line 167 of file
…/mbed/targets/hal/TARGET_NXP/TARGET_LPC176x/can_api.chttps://github.com/mbedmicro/mbed/blob/master/libraries/mbed/targets/hal/TARGET_NXP/TARGET_LPC176X/can_api.c
.


Reply to this email directly or view it on GitHubhttps://github.com//issues/56
.

@bogdanm bogdanm closed this as completed Sep 11, 2013
bridadan pushed a commit that referenced this issue Jun 21, 2016
hasnainvirk pushed a commit to hasnainvirk/mbed-os that referenced this issue Feb 12, 2017
… from a1982c1..e125164

e125164 Check secure session pointer in timer callback (ARMmbed#61)
f49e596 Update unit tests (ARMmbed#59)
6a5634a Support for multiple virtual services (ARMmbed#58)
7fe6b98 Remove yotta files (ARMmbed#57)
5c5c8fe Fix socket send return value overflow (ARMmbed#56)
0870d05 Update unit test stubs to match latest socket api (ARMmbed#55)
e687be8 Merge pull request ARMmbed#54 from ARMmbed/warn_fixes
b8fe613 updated unittests
8640d05 Compilation warnings fixed
eea83e5 Flag out entropy source addition (ARMmbed#53)
7d72eb4 Fix unittests (ARMmbed#52)
4a6991e Avoid referencing ns_msghdr_t::flags

git-subtree-dir: features/nanostack/FEATURE_NANOSTACK/coap-service
git-subtree-split: e125164
geky pushed a commit to geky/mbed that referenced this issue Aug 25, 2018
Add SD card reader support over DISCO_L476VG platform for running Cloud Client.
linlingao pushed a commit to linlingao/mbed-os that referenced this issue Jul 12, 2019
Update to latest version of Mbed OS
Jookia pushed a commit to Jookia/mbed-os that referenced this issue Mar 11, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants