[SOLVED] J-Link Debugger crashes when loading GHS .elf file

mariusene · Oct 5th 2015, 4:31pm

Hello,

I am trying to use J-Link Debugger V1.78 with an .elf file generated using Green Hills compiler suite(GHS).
When using the New Project Wizard, after selecting the .elf file, the program crashes. I am able to load an .elf file generated with GCC, so I believe there is an error with the .elf format generated by GHS.

I have found a topic which I think describes a similar problem, stating that some compiler .elfs are not supported:
[SOLVED] JScope crashes

Is this compiler output not supported?
I would appreciate any advice and I am sorry if this is an inappropriate questions(I am a beginner with these tools).

Thank you,
Marius

SEGGER - Niklas · Oct 6th 2015, 8:55am

Hello Marius,

thanks for your inquiry. Would it be possible to provide us an elf file and / or the project (or another project) for reproduction purposes?
If you do not want to post it here, you can send me a download link via Personal Message, or we can continue this conversation via mail.

Best regards,
Niklas

mariusene · Oct 6th 2015, 11:07am

Hello,

Thank you for your quick reply. I attach an .elf file which causes the crash.

SEGGER - Alex · Oct 6th 2015, 7:50pm

Hi,

Thanks for providing the ELF file.
We can reproduce the problem and will fix it in the J-Link Debugger.

- Alex

mariusene · Oct 7th 2015, 10:08am

Thank you for your support.

SEGGER - Alex · Oct 8th 2015, 2:47pm

Hi,

We have added a preliminary fix for this.
Anyhow, the ELF information looks somewhat strange for the case where J-Link Debugger crashed.
Would it be possible to explain how dataPtrUnaligned is declared in your source code?
The code should look like below.
Anyhow, we are curious of what type dataPtrUnaligned is.
void* dataPtrUnaligned?

C Source Code

C:/tools/tresos_14_2_1/plugins/Fls_TS_T40D2M8I0R0/src/Fls.c
Fls_Flash_SectorRead(phySector, sectorOffset, dataLength, dataPtr) {
[var] initDataLength;
[var] RetVal;
[var] readAddressEndPtr;
[var] readBlockAddressEndPtr;
[var] dataPtrUnaligned;
}

Best regards
Alex

mariusene · Oct 9th 2015, 2:29pm

Hi,

The code looks like that and dataPtrUnaligned variable is defined like:

__packed P2VAR(uint32, AUTOMATIC, FLS_APPL_DATA) volatile dataPtrUnaligned = NULL_PTR;

The __packed qualifier is needed because of a pointer typecast; a similar usecase is described in more detail in the link below, under Compiler assumptions paragraph:
infocenter.arm.com/help/index.…arm.doc.faqs/ka15414.html

Thank you and please tell me if I can provide more details.

Marius

SEGGER - Niklas · Oct 9th 2015, 3:11pm

Hi,

thanks for sharing this information.

Thank you and please tell me if I can provide more details.

Would it be possible to provide us with the definition of the P2VAR macro? (And optional, of AUTOMATIC and FLS_APPL_DATA ?)
We are still researching if GHS generates a faulty .elf file or if GHS interprets the ELF/DWARF specs in a way we are not yet compatible with.

Best regards,
Niklas

mariusene · Oct 9th 2015, 3:23pm

FLS_APPL_DATA and AUTOMATIC are empty defines, so
__packed P2VAR(uint32, AUTOMATIC, FLS_APPL_DATA) volatile dataPtrUnaligned = NULL_PTR;
would translate to:
__packed uint32 * volatile dataPtrUnaligned = NULL_PTR;

Thank you,
Marius

Veit_Kannegieser · Oct 11th 2015, 1:17pm

the P2VAR and similar macros come from the AUTOSAR world,
it is resolved in an compiler abstraction header and
P2VAR(uint32, AUTOMATIC, FLS_APPL_DATA)
should result in uint32 *
possibly in data section defined by FLS_APPL_DATA, which i guess as a flash driver variable.

We use GHS and IAR and i had to write tools to convert GHS compiled obect files to be linkable and running with IAR.
My understanding is that GHS has a different opionion about reloactions, ABI markup..

Veit_Kannegieser · Oct 11th 2015, 1:25pm

One more comment:
the GHS compiler and IDE works with the GHS probes (price it a lot higher then a J-Link) and you need a license to use the probes.
GHS multi has support for other probes too (MACRAIGOR, HP), but RDI support seem to be gone now.
The interface of the multi debug probe interface (like rtserv.exe) is not public documented.
Would be a dream to have GHS multi working with J-Link!

SEGGER - Niklas · Oct 13th 2015, 7:07pm

Hi,

IDE support is doable if the IDE either supports a generic API like GDB or RDI or provides a documented API.
If time intensive reverse engineering is required, IDE support will most likely only implemented on heavy public demand or customer order.

Best regards,
Niklas

Veit_Kannegieser · Oct 15th 2015, 9:04pm

Hello Niklas,

i have asked our Green Hills support, and the interfaces are not public.

Also from support point - who is in responsible in case of problems: user, GHS, Segger, chip manufacturer,..
and i guess also from buisiness view there is no reason for GHS.

SEGGER - Niklas · Oct 26th 2015, 9:55am

Hi Marius,

the issue has been fixed in V1.79a of J-Link Debugger.

Best regards,
Niklas

mariusene · Oct 26th 2015, 10:03am

Hi Niklas,

It works, thanks a lot for your support.

Best regards,
Marius

C Source Code

Share