Mbed-os: M487: Crash report test failed in IAR

Created on 12 Dec 2018  路  23Comments  路  Source: ARMmbed/mbed-os

Description

Target:
NUMAKER_PFM_M487

Toolchain:
IAR

mbed-os:
0a832dd6e0 (HEAD -> master, origin/master, origin/HEAD) Merge pull request #9051 from michalpasztamobica/esp8266_busy_signal

The test item mbed-os-tests-mbed_platform-crash_reporting / mbed-os-tests-mbed_platform-crash_reporting is passed in ARM/ARMC6/GCC_ARM, but failed in IAR. Per my checking, the crash data ram base/limit __CRASH_DATA_RAM_START__/__CRASH_DATA_RAM_END__ calculated in M487.icf are incorrect because IAR linker doesn't arrange memory as simply expected.

In mbed-os/targets/TARGET_NUVOTON/TARGET_M480/device/TOOLCHAIN_IAR\M487.icf:

/* Define Crash Data Symbols */
define exported symbol __CRASH_DATA_RAM_START__ = __ICFEDIT_region_IRAM_start__ + __ICFEDIT_size_cstack__ + __ICFEDIT_size_intvec__;
define exported symbol __CRASH_DATA_RAM_END__ = __ICFEDIT_region_IRAM_start__ + __ICFEDIT_size_cstack__ + __ICFEDIT_size_intvec__ + __ICFEDIT_size_crash_data__;

In mbed-os/platform/mbed_crash_data_offsets.h:

#if MBED_CONF_PLATFORM_CRASH_CAPTURE_ENABLED
#if defined(__CC_ARM) || (defined(__ARMCC_VERSION) && (__ARMCC_VERSION >= 6010050))
extern uint32_t Image$$RW_m_crash_data$$ZI$$Base[];
extern uint32_t Image$$RW_m_crash_data$$ZI$$Size;
#define __CRASH_DATA_RAM_START__    Image$$RW_m_crash_data$$ZI$$Base
#define __CRASH_DATA_RAM_SIZE__     Image$$RW_m_crash_data$$ZI$$Size
#elif defined(__ICCARM__)
extern uint32_t __CRASH_DATA_RAM_START__[];
extern uint32_t __CRASH_DATA_RAM_END__[];
#define __CRASH_DATA_RAM_SIZE__     (__CRASH_DATA_RAM_END__ - __CRASH_DATA_RAM_START__)
#elif defined(__GNUC__)
extern uint32_t __CRASH_DATA_RAM_START__[];
extern uint32_t __CRASH_DATA_RAM_END__[];
#define __CRASH_DATA_RAM_SIZE__     (__CRASH_DATA_RAM_END__ - __CRASH_DATA_RAM_START__)
#endif /* defined(__CC_ARM) */

If I change __CRASH_DATA_RAM_START__/__CRASH_DATA_RAM_END__ as below, the test is passed. But this change cannot apply to all targets because CRASH_DATA_RAM is defined only in NUMAKER_PFM_M487 target or some.

#elif defined(__ICCARM__)
extern uint32_t CRASH_DATA_RAM$$Base[];
extern uint32_t CRASH_DATA_RAM$$Limit[];
#define __CRASH_DATA_RAM_START__    CRASH_DATA_RAM$$Base
#define __CRASH_DATA_RAM_END__      CRASH_DATA_RAM$$Limit
#define __CRASH_DATA_RAM_SIZE__     (__CRASH_DATA_RAM_END__ - __CRASH_DATA_RAM_START__)

Besides, checking mbed-os/platform/mbed_crash_data_offsets.h, the unit of __CRASH_DATA_RAM_SIZE__ doesn't match across all toolchains. In ARM/ARMC6, it is byte, but in IAR/GCC_ARM, it is word.

Issue request type

[ ] Question
[ ] Enhancement
[x] Bug
CLOSED mirrored bug
Source
picture ccli8

All 23 comments

Internal Jira reference: https://jira.arm.com/browse/MBOCUSTRIA-303

ciarmcom picture ciarmcom on 12 Dec 2018

Just to confirm, this is the issue specific to M487 only ?

0xc0170 picture 0xc0170 on 13 Dec 2018

@0xc0170 The issue happens on M487 and possibly on other Nuvoton targets if crash report support is added as M487. This is because the common code __CRASH_DATA_RAM_START__/__CRASH_DATA_RAM_END__ cannot be simply calculated out in M487 IAR .icf file. For other non-Nuvoton targets, I cannot confirm because IAR linker may or may not arrange memory as __CRASH_DATA_RAM_START__/__CRASH_DATA_RAM_END__ can be simply calculated out.

ccli8 picture ccli8 on 14 Dec 2018

@SenRamakri Fyi ^^^

cmonr picture cmonr on 14 Dec 2018

Hi @ccli8 , is this still an issue? What's pending? Thanks.

samchuarm picture samchuarm on 10 Jan 2019

is this still an issue? What's pending? Thanks.

@samchuarm This issue happens on M487 and might also happen on other targets. Expect mbed team could come out with a general solution.

ccli8 picture ccli8 on 11 Jan 2019

@samchuarm This issue happens on M487 and might also happen on other targets. Expect mbed team could come out with a general solution.

@ARMmbed/mbed-os-core Can you review this issue please?

0xc0170 picture 0xc0170 on 15 Jan 2019

@ccli8 - I'm trying to investigate this. Unfortunately I don't have M487 board and so cant really try. DO you know if this is reproducible in any other Nuvoton boards?

Btw, I tried to compile for M487 and I do see the below symbols defined in Map file and they are 0x100 apart. So, I'm thinking symbols are exported as required and of course, they are defined as the compilation succeeds. Its possible that icf is not properly configured. I'm looking more into this.

__CRASH_DATA_RAM_END__ {Abs}
0x200006c0 Data Gb command line/config [164]
__CRASH_DATA_RAM_START__ {Abs}
0x200005c0 Data Gb command line/config [164]

SenRamakri picture SenRamakri on 22 Jan 2019

@SenRamakri Following M487, I privately add crash report support to NUMAKER_PFM_NUC472 and can reproduce the same issue and its fix. I think all Nuvoton targets would suffer the same issue. In my opinion, like my fix above, all targets supporting crash report shall define the CRASH_DATA_RAM block. __CRASH_DATA_RAM_START__/__CRASH_DATA_RAM_END__ can then be derived from the block rather than calculated manually.

#elif defined(__ICCARM__)

extern uint32_t CRASH_DATA_RAM$$Base[];
extern uint32_t CRASH_DATA_RAM$$Limit[];

#define __CRASH_DATA_RAM_START__    CRASH_DATA_RAM$$Base
#define __CRASH_DATA_RAM_END__      CRASH_DATA_RAM$$Limit
#define __CRASH_DATA_RAM_SIZE__     (__CRASH_DATA_RAM_END__ - __CRASH_DATA_RAM_START__)
ccli8 picture ccli8 on 23 Jan 2019

@ccli8 - I see your point although we are not seeing this with other targets. I think for some reason the alignment we are using for different blocks in M487.icf is messing up with placement of crash_data block. I'm looking more into this now.

SenRamakri picture SenRamakri on 23 Jan 2019

Hi

We are seeing this test fail as well on the k64 frdm board with IAR. Not sure if this helps, but here is the info from verbose when the test errors out.

++ MbedOS Error Info ++
[1550526552.16][CONN][RXD] Error Status: 0x80FF011F Code: 287 Module: 255
[1550526552.21][CONN][RXD] Error Message: Executing crash reporting test.
[1550526552.23][CONN][RXD] Location: 0x0
[1550526552.25][CONN][RXD] Error Value: 0xDEADBAD
[1550526552.37][CONN][RXD] Current Thread: main Id: 0x200002B0 Entry: 0x1C81 StackSize: 0x1000 StackMem: 0x20000310 SP: 0x200012A0
[1550526552.46][CONN][RXD] For more info, visit: https://armmbed.github.io/mbedos-error/?error=0x80FF011F
[1550526552.48][CONN][RXD] -- MbedOS Error Info --

Thanks,
Sathy

sathysreenath picture sathysreenath on 18 Feb 2019

@sathysreenath How to reproduce this failure? Any small code snippet available?

0xc0170 picture 0xc0170 on 19 Feb 2019

Hi,

Sorry, never mind, one of the options from app json config file was causing the test to fail. Thanks for your time.

Sathy.

sathysreenath picture sathysreenath on 19 Feb 2019
👍1

Why close the issue? I re-test on master branch (f61dee1626 Merge pull request #9774 from 0xc0170/fix_license_md), but it still exists.

ccli8 picture ccli8 on 21 Feb 2019
👍1

Based on the answer above, it was closed as user error. As I can see now it did not answer earlier reports, bug still valid

0xc0170 picture 0xc0170 on 21 Feb 2019

@ccli8 My mistake. I thought @sathysreenath was the original author of the issue.

cmonr picture cmonr on 22 Feb 2019

@ccli8 trying to reproduce the problem on NUMAKER_PFM_M487

1) I don't have any luck getting uart logs on both windows and linux.

nulink firmware : NuLink1FW_v6786
test code 

#include "mbed.h"

DigitalOut led_red(LED_RED);
DigitalOut led_green(LED_GREEN);

int main()
{
    int count = 0;
    while (true)
    {
        led_red = !led_red;
        wait(1);
        led_green =!led_green;
        printf("counter value : %d \r\n",++count);
    }
}

I do see red and green led blinking, can you please help with setting to enable uart logs.

2) Exporting to IAR doesn't work for NUMAKER_PFM_M487

i tried to export to debug using IAR Embedded Workbench IDE had no luck 

C:\repos\mbed-os-example-blinky>mbed export -m NUMAKER_PFM_M487 -i IAR -v
[mbed] Working path "C:\repos\mbed-os-example-blinky" (program)
[mbed] Exec "c:\python27\python.exe -u C:\repos\mbed-os-example-blinky\mbed-os\tools\project.py -i iar -m NUMAKER_PFM_M487 --profile debug --source ." in "C:\repos\mbed-os-example-blinky"
NUMAKER_PFM_M487 not supported by iar
[mbed] ERROR: "c:\python27\python.exe" returned error.
       Code: 2
       Path: "C:\repos\mbed-os-example-blinky"
       Command: "c:\python27\python.exe -u C:\repos\mbed-os-example-blinky\mbed-os\tools\project.py -i iar -m NUMAKER_PFM_M487 --profile debug --source ."
       Tip: You could retry the last command with "-v" flag for verbose output

I thought adding below should enable the exporter support, but need to entry for M487JIDAE in https://github.com/ARMmbed/mbed-os/blob/master/tools/arm_pack_manager/index.json i am not sure how to proceed.

diff --git a/tools/export/iar/iar_definitions.json b/tools/export/iar/iar_definitions.json
index 9dca4c713e..d8f68f288a 100644
--- a/tools/export/iar/iar_definitions.json
+++ b/tools/export/iar/iar_definitions.json
@@ -261,6 +261,9 @@
     "M453VG6AE": {
         "OGChipSelectEditMenu": "M453VG6AE\tNuvoton M453VG6AE"
     },
+    "M487JIDAE": {
+        "OGChipSelectEditMenu": "M487JIDAE\tNuvoton M487JIDAE"
+    },
     "nRF52840_xxAA":{
         "OGChipSelectEditMenu": "nRF52840_xxAA\tNordicSemi nRF52840_xxAA",
         "CExtraOptionsCheck": 1
studavekar picture studavekar on 29 Mar 2019

For UART log, I test on the environment, but it is OK:

  • Win10 64-bit
  • NuMaker-PFM-M487 Ver 3.0
  • Nu-Link 6786
  • mbed-os 594a1d180b4fdddd19359f2628e6f5b998bb5e16

Please check the following items:

  1. Your NuMaker-PFM-M487 board is Ver3.0 (print on board top).
  2. Serial port is successfully listed (e.g. mbedls)

For export IAR project, please apply PR #10282 and make extra patch.

ccli8 picture ccli8 on 1 Apr 2019

Your NuMaker-PFM-M487 board is Ver3.0 (print on board top).

Yes

Serial port is successfully listed (e.g. mbedls)

mbedls do show up the serial port

Exporter did work for me, as suggested in you're solution i am not able to find symbol CRASH_DATA_RAM$$Base and CRASH_DATA_RAM$$Limit

studavekar picture studavekar on 2 Apr 2019

For serial issue, please also check ISW1 (4-switch with TXD/RXD/VCOM/MSG) near USB socket on the board (reference board page). Make sure all these TXD/RXD/VCOM switches adjust to outside. MSG switch is to control Mass mode (adjust to outside) or Debug mode. (adjust to inside) If still failed, would you double-check with another NuMaker-PFM-M487 board?

i am not able to find symbol CRASH_DATA_RAM$$Base and CRASH_DATA_RAM$$Limit

To generate these symbols, you need to use them, like:

#include "mbed.h"
DigitalOut led_red(LED_RED);
DigitalOut led_green(LED_GREEN);

extern uint32_t CRASH_DATA_RAM$$Base[];
extern uint32_t CRASH_DATA_RAM$$Limit[];

int main()
{
    printf("CRASH_DATA_RAM$$Base=%p, CRASH_DATA_RAM$$Limit=%p\r\n", CRASH_DATA_RAM$$Base, CRASH_DATA_RAM$$Limit);

    int count = 0;
    while (true)
    {
        led_red = !led_red;
        wait(1);
        led_green =!led_green;
        printf("counter value : %d \r\n",++count);
    }
}
ccli8 picture ccli8 on 3 Apr 2019

After further debugging the root cause of problem is

1) Out-of-Order placement of block.
2) IAR optimization if block is not referenced in code.

1) Out-of-Order placement of block.

The placement of block might be Out-Of-Order and which would lead to wrong values of __CRASH_DATA_RAM_START__ and __CRASH_DATA_RAM_END__

FIX :

Define the blocks in fixed order using, this would results in correct calculation of __CRASH_DATA_RAM_START__ and __CRASH_DATA_RAM_END__, However block would still be optimized out.

define block FIXED_ORDER_IRAM with fixed order { block CSTACK, 
                                                block IRAMVEC,
                                                CRASH_DATA_RAM};

place at start of IRAM_region   { block FIXED_ORDER_IRAM };
place in IRAM_region   { block  };
place in IRAM_region   { readwrite };
place in XRAM_region   { block XRAM_NC, block HEAP };

2) IAR optimizes if block is not referenced in code

Memory block is optimized out when we don't have reference to CRASH_DATA_RAM$$Base and CRASH_DATA_RAM$$Limit.

FIX :

Define and use the symbol CRASH_DATA_RAM$$Base or CRASH_DATA_RAM$$Limit somewhere in code, with ordered block. We see all blocks are ordered and __CRASH_DATA_RAM_START__ and __CRASH_DATA_RAM_END__ points to correct memory location

Proposed fix

Take out the definition of __CRASH_DATA_RAM_START__ and __CRASH_DATA_RAM_END__ from linker script for IAR and use CRASH_DATA_RAM$$Base and CRASH_DATA_RAM$$Limit so that block doesn't get optimized out.

@ccli8 suggested fix would be appropriate, Thanks @ccli8 

#elif defined(__ICCARM__)
extern uint32_t CRASH_DATA_RAM$$Base[];
extern uint32_t CRASH_DATA_RAM$$Limit[];
#define __CRASH_DATA_RAM_START__    CRASH_DATA_RAM$$Base
#define __CRASH_DATA_RAM_END__      CRASH_DATA_RAM$$Limit
#define __CRASH_DATA_RAM_SIZE__     (__CRASH_DATA_RAM_END__ - __CRASH_DATA_RAM_START__)
studavekar picture studavekar on 4 Apr 2019

@studavekar From test log in #10311, it seems that you have fixed serial port issue on NuMaker-PFM-M487 board. What's the cause?

ccli8 picture ccli8 on 8 Apr 2019

@studavekar From test log in #10311, it seems that you have fixed serial port issue on NuMaker-PFM-M487 board. What's the cause?

No didn't had luck with the boards used a different device :(

studavekar picture studavekar on 8 Apr 2019
Was this page helpful?
0 / 5 - 0 ratings

Related issues

pilotak picture pilotak  路  3Comments
bulislaw picture bulislaw  路  3Comments
1domen1 picture 1domen1  路  3Comments
neilt6 picture neilt6  路  4Comments
hasnainvirk picture hasnainvirk  路  3Comments