Error launching Lauterbach Trace32 debugger

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

Error launching Lauterbach Trace32 debugger

跳至解决方案
1,618 次查看
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,544 次查看
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,545 次查看
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,520 次查看
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,555 次查看
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 项奖励
回复