Hi,
Please find it attached.
Hi,
Please find it attached.
Hi,
Yes, I've read that guide from top to bottom.
I think everything is setup correctly, but maybe you can make a better judgment based on the provided screenshot?
Did I miss something somewhere?
Hi,
Because JScope HSS sampling is currently not working for me (see https://forum.segger.com/index.php/Thre…initialize-HSS/), I'm trying to get JScope working using RTT mode.
I've configured an up buffer and write data to it. The RTT viewer can find the control block almost immediately and shows the additional channel:
But when I then start JScope it tries to find the control block for a while and then bails out with the message that the control block can not be found.
Did I configure something wrong?
Thanks in advance.
Kind regards,
Remco Poelstra
Hi,
I'm sorry about the confusion. I meant V794d.
I just tried V794e and it shows the same problem.
Before trying V794d I was using V792c, and I downloaded V794d in the hope it was already fixed.
I've tried V788h as well, as it was still on my system. It fails as well.
On Win11, V788m gave the exact same error message. I don't know if it ever worked on Win11 for me, I've never used it there.
Given the fact that I've used JScope successfully a few months ago, I would come to believe that the probe's firmware is at fault and not the JScope application. But this is just a feeling. I don't know which FW version was on the probe in the past.
Please let me know if there is anything I can test for you.
Hi,
I'm trying to use J-Scope, but as soon as a click 'start' I get the message 'Failed to initialize HSS'.
I've used J-Scope in the recent past on the same host and target successfully, and debugging using MCUXpresso and the J-Link still works fine.
I'm not aware that I changed anything that might break J-Scope's functioning and the error message doesn't provide a clue unfortunately.
How can I get J-Scope working again?
J-Link software 749d
macOS 14.1.2 (Apple M1)
LPC844M201
Thanks in advance.
Kind regards,
Remco Poelstra
Hi,
I just switched to SES 6.32a from 6.20a. When I compile my project in Release mode and try to run on an nRF52840 then the code crashes somewhere early. The code runs fine when build in Debug mode. I've tried to disable LTO, but that didn't help.
In 6.20a the code runs fine in both Debug as well as Release mode.
I'm not sure on how to tackle this issue as it's difficult to find out where it exactly crashes in Release mode as there is no debug information anymore.
Thanks in advance.
Kind regards,
Remco Poelstra
Hi,
I've the following format specifier in a snprintf function:
Unfortunately, this results in the string '255', instead of -1. When I remove the 'hh' part, then -1 is correctly converted to '-1'.
I've set the 'Printf Width/Precision supported' to Yes in the project configuration.
I'm using SES 5.42 on a Mac.
Is this a bug?
Thanks in advance.
Kind regards,
Remco Poelstra
Hi Nino,
Thanks for your answer. I'm very sorry for my late reply, I was waiting for a mail from the system that there was a reply but never received it.
I've tried both setting the 'default fill pattern' to 0xff as well as adding a 'fill="0xff"' attribute to the MemorySegment in the flash_placement.xml, but the UICR section is still filled with all 0's. Did I set the wrong option?
Hi,
I'm using SES 4.52b with a (custom) nR52840 board.
SES generates both .elf and .hex files.
I've defined the following MemorySegment in the flash_placement.xml:
<MemorySegment name="UICR" start="0x10001000" size="0x308">
<ProgramSection alignment="4" keep="Yes" load="Yes" name=".uicr_bootloader_start_address" address_symbol="__start_uicr_bootloader_start_address" end_symbol="__stop_uicr_bootloader_start_address" start = "0x10001014" size="0x4" />
<ProgramSection alignment="4" keep="Yes" load="Yes" name=".uicr_mbr_params_page" address_symbol="__start_uicr_mbr_params_page" end_symbol="__stop_uicr_mbr_params_page" start = "0x10001018" size="0x4" />
<ProgramSection alignment="4" keep="Yes" load="Yes" name=".uicr_regout0" start="0x10001304" size="4"/>
</MemorySegment>
When I now start the debugger (which loads the .elf) the unused sections in this MemorySegment are filled with 0's. When I load the .hex file, the unused sections are properly filled with 0xff.
Is this a bug in the .elf loader? Or is there a way to make sure the unused sections remain untouched while loading an .elf?
Thanks in advance.
Kind regards,
Remco Poelstra