Error launching Lauterbach Trace32 debugger

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

Error launching Lauterbach Trace32 debugger

ソリューションへジャンプ
2,055件の閲覧回数
elizabeth_gerag
Contributor II

I have created an S32R294 test application using File->New->S32DS Application Project. I'm using the diab toolchain. I haven't made any changes to the application that was created. It built successfully but when I tried to launch the Lauterbach Trace32 debugger I got this error:

Pasted Graphic 3.png

The details were:

"An internal error occurred during: "Launching TestProject_Z4_0_RAM_Lauterbach".Illegal/unsupported escape sequence near index 3

C:\iss\s32r\source\workspaces\S32R294_new_dev\TestProject\TestProject_Z4_0/Project_Settings/Debugger/ram.cmm"

I'm not sure what index 3 is referring to but that path, which is valid, must be from the PRACTICE script field in the debug configuration which is:

${ProjDirPath}\Project_Settings\Debugger\ram.cmm ${ConfigName} ${ProjName}.elf

As I said I haven't changed anything and everything was all auto-generated so I'm not sure what the issue is. Do I need to change something somewhere to get it to work?

Thanks,

Liz

0 件の賞賛
返信
1 解決策
1,981件の閲覧回数
elizabeth_gerag
Contributor II

Hi Mike,

Thanks for the reply. I tried your suggestion and added the absolute path in place of ${ProjDirPath} in the PRACTICE script setting. While the internal error no longer popped up and TRACE32 was now launched, the script wasn't being executed. TRACE32 didn't show any errors but when I closed TRACE32, S32DS popped up this error:

"Trace32 could not execute command'do C:/iss/liz/projects/test/s32r294/source/testproj/testprojsource/Diab_build_S32R294/TestProject/TestProject_Z4_0/
iss/liz/projects/test/s32r294/source/testproj/testprojsource/Diab_build_S32R294/TestProjectProject_Settings/Debugger/ram.cmm Debug TestProject_Z4_0.elf ' at line {1}.
Invalid parameter: command length"

I noticed the path to the script file had the project path in there twice. In the debug configuration there's a setting for Initial Working Directory which is set to  ${ProjDirPath}. I thought that might be where the duplicate project path was coming from so I modified the PRACTICE script setting to remove ${ProjDirPath} altogether and set it to:

./Project_Settings/Debugger/ram.cmm ${ConfigName} ${ProjName}.elf

Now when I launch it, TRACE32 comes up and the script runs successfully.

Thanks,

Liz

元の投稿で解決策を見る

3 返答(返信)
1,982件の閲覧回数
elizabeth_gerag
Contributor II

Hi Mike,

Thanks for the reply. I tried your suggestion and added the absolute path in place of ${ProjDirPath} in the PRACTICE script setting. While the internal error no longer popped up and TRACE32 was now launched, the script wasn't being executed. TRACE32 didn't show any errors but when I closed TRACE32, S32DS popped up this error:

"Trace32 could not execute command'do C:/iss/liz/projects/test/s32r294/source/testproj/testprojsource/Diab_build_S32R294/TestProject/TestProject_Z4_0/
iss/liz/projects/test/s32r294/source/testproj/testprojsource/Diab_build_S32R294/TestProjectProject_Settings/Debugger/ram.cmm Debug TestProject_Z4_0.elf ' at line {1}.
Invalid parameter: command length"

I noticed the path to the script file had the project path in there twice. In the debug configuration there's a setting for Initial Working Directory which is set to  ${ProjDirPath}. I thought that might be where the duplicate project path was coming from so I modified the PRACTICE script setting to remove ${ProjDirPath} altogether and set it to:

./Project_Settings/Debugger/ram.cmm ${ConfigName} ${ProjName}.elf

Now when I launch it, TRACE32 comes up and the script runs successfully.

Thanks,

Liz

1,957件の閲覧回数
mikedoidge
NXP Employee
NXP Employee

Hello Liz,

Thanks for identifying this bug. Unfortunately, there is no plans for any update to this product so we don't have an opportunity to fix it. Hopefully this thread will server as a source for solving this issue for future users.

Best Regards,

Mike

0 件の賞賛
返信
1,992件の閲覧回数
mikedoidge
NXP Employee
NXP Employee

Hello Liz,

Sorry for the delay. I am looking into this. I was able to reproduce the issue. I have found a temporary workaround. If you manually specify the absolute path using only '/', in place of the macro ${ProjDirPath}, then the error is gone. I'll update you once I have a more permanent fix.

Best Regards,

Mike

0 件の賞賛
返信