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

M487: Crash report test failed in IAR #9069

Closed
ccli8 opened this issue Dec 12, 2018 · 23 comments

Comments

Projects
None yet
8 participants
@ccli8
Copy link
Contributor

commented Dec 12, 2018

Description

Target:
NUMAKER_PFM_M487

Toolchain:
IAR

mbed-os:
0a832dd (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
@ciarmcom

This comment has been minimized.

Copy link
Member

commented Dec 12, 2018

@ciarmcom ciarmcom added the mirrored label Dec 12, 2018

@0xc0170

This comment has been minimized.

Copy link
Member

commented Dec 13, 2018

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

@ccli8

This comment has been minimized.

Copy link
Contributor Author

commented Dec 14, 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.

@cmonr

This comment has been minimized.

Copy link
Contributor

commented Dec 14, 2018

@SenRamakri Fyi ^^^

@samchuarm

This comment has been minimized.

Copy link

commented Jan 10, 2019

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

@ccli8

This comment has been minimized.

Copy link
Contributor Author

commented Jan 11, 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.

@0xc0170

This comment has been minimized.

Copy link
Member

commented Jan 15, 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?

@SenRamakri

This comment has been minimized.

Copy link
Collaborator

commented Jan 22, 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]

@ccli8

This comment has been minimized.

Copy link
Contributor Author

commented Jan 23, 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__)
@SenRamakri

This comment has been minimized.

Copy link
Collaborator

commented Jan 23, 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.

@sathysreenath

This comment has been minimized.

Copy link

commented Feb 18, 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

@0xc0170

This comment has been minimized.

Copy link
Member

commented Feb 19, 2019

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

@sathysreenath

This comment has been minimized.

Copy link

commented Feb 19, 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.

@ccli8

This comment has been minimized.

Copy link
Contributor Author

commented Feb 21, 2019

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

@0xc0170

This comment has been minimized.

Copy link
Member

commented Feb 21, 2019

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

@cmonr

This comment has been minimized.

Copy link
Contributor

commented Feb 22, 2019

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

@studavekar

This comment has been minimized.

Copy link
Contributor

commented Mar 29, 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
@ccli8

This comment has been minimized.

Copy link
Contributor Author

commented Apr 1, 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 594a1d1

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.

@studavekar

This comment has been minimized.

Copy link
Contributor

commented Apr 2, 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

@ccli8

This comment has been minimized.

Copy link
Contributor Author

commented Apr 3, 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);
    }
}
@studavekar

This comment has been minimized.

Copy link
Contributor

commented Apr 3, 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__)
@ccli8

This comment has been minimized.

Copy link
Contributor Author

commented Apr 8, 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?

@studavekar

This comment has been minimized.

Copy link
Contributor

commented Apr 8, 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 :(

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.