Posts by spiff

Hello,
I am struggling with getting EmbOS thread-aware debugging working in Eclipse.

I have previously had this working, but since my development PC has been replaced and everything reinstalled, I cannot make it work now.
I have updated JLink to the latest version 7.84c. The target application is still EmbOS 5.02, and linked with libosT7LDP.a.

I have added the option "-rtos GDBServer/RTOSPlugin_embOS.dll" to the GDB server configuration, but when I attach to the running target, I do not see other threads. I also tried ticking the "Force thread list update on suspend", but it made no difference.

I have attempted to enable GDB server logging, and the log file contains the following lines:

03-00000000-00-00000815-0037: Loading RTOS plugin: GDBServer/RTOSPlugin_embOS.dll...
03-00000000-00-00000816-002B: RTOS plugin (API v1.0) loaded successfully

If I try to set a non-existent filename for the -rtos-option, I get an error message here that the file does not exist, so it seems the DLL is indeed loaded, but somehow it still does not show the threads.

Any suggestions for how to proceed are very welcome.

Best regards,
Mikkel Holm Olsen

Thank you Til.

I will look into the option of upgrading.

Best regards
Mikkel Holm Olsen

Hello.

I am using EmbOS CortexM GCC V5.02 on an ATSAM4E8C.

I have a function which I would like to take different code paths if called from a thread or from a timer or interrupt handler.

Basically my function is normally called from a task, but because it uses a MUTEX, this will fail with OS Error 161 if called from a timer handler or 160 if called from an ISR.

Is it possible to determine if my function is called from a timer or interrupt handler, so I can take a different code path, avoiding trying to acquire the mutex?

I would like to do something like the following:

if (OS_InTimerHandler() || OS_In_ISR()) {
  do_something_special();
} else {
  if (0==OS_MUTEX_LockTimed(&my_mutex, 100)) {
    error_mutex_timeout();
  } else {
    do_something_that_requires_mutex();
    OS_MUTEX_Unlock(&my_mutex);
  }
}

Note: The function also performs a number of other things before and after the mutex, so replacing all calls from within timer and interrupt handlers with a special version is not desirable.

Best regards
Mikkel Holm Olsen

Dear Fabian,

Thank you for the quick reply. I have just done a little testing, and it appears I can make it work with the following command line:

start /min /wait "J-Flash" jflash.exe -openprjtest.jflash -readrange0x00C00000,0x00C001FF -saveasusig.bin,0x00C00000,0x00C001FF -exit

Thank you for also adding it to the JLink Commander feature request list.

Best regards,
Mikkel Holm Olsen

The MCU I am using has a 128-bit unique identifier, which I would like to read out during production programming. Unfortunately the UID is not mapped into the normal memory space. My initial idea was to make a Flash Loader (ramcode/applet) to read out the UID, but I am not quite clear on how to do this because the write-function is mandatory, but writing to the UID area is of course not possible.

Also, as explained in my other thread:
https://forum.segger.com/index.php/Thre…user-signature/
reading using JLink Commander does not seem to work unless an erase/write was performed first (seems the ramcode/applet is not loaded by read).

I would like to use JLink Commander to read out the UID. Any suggestions on how to do this with a ramcode/applet (i.e. is it possible to load the ramcode/applet and use it for read)?

An alternative approach could be to write a small piece of code that can be loaded into RAM using loadfile, then executed with setPC and go, and the code would copy the UID to a known (RAM) memory location, allowing it to be read out using mem or savebin commands. Any pointers for how to proceed with this approach are very welcome, as this is uncharted territory for me.

If anyone can come up with a different approach to reading out the UID usind a command line tool on Windows, I am happy to hear your suggestion. I would prefer to read this out using JTAG only, not the UART or similar.

As a side note, I spent a decent amount of time looking into customizing Atmels SAM-BA 2.18, as that supports reading out the UID. Unfortunately whan using SAM-BA with JLink, the JLink device selector pops up (actually 3 times), so using from a script/command line is not practical.

Best regards,
Mikkel Holm Olsen

I need to program the User Signature Area on SAM4E (store production data, serial number, calibration, etc.)

I found this thread with a person requesting writing the user signature area on a different SAM4 MCU, but there is no reply and the thread is 3 years old:
https://forum.segger.com/index.php/Thre…ing-via-J-Link/

I have written a Flash Loader (ramcode/applet) and included it in JLinkDevices.xml. I can erase the User Signature area using J-Link commander:

J-Link>exec EnableEraseAllFlashBanks
J-Link>erase 0x00C00000 0x00C001FF
Erasing selected range...
J-Link: Flash download: Total time needed: 0.129s (Prepare: 0.018s, Compare: 0.000s, Erase: 0.065s, Program: 0.000s, Ver
ify: 0.000s, Restore: 0.046s)
J-Link: Flash download:
Flash sectors within Range [0x00C00000 - 0x00C001FF] deleted.
Erasing done.

I can write to the User Signature Area (which includes read/verify):

J-Link>loadfile c:\test\usig_src.bin 0x00C00000
Downloading file [c:\test\usig_src.bin]...
J-Link: Flash download: Bank 1 @ 0x00C00000: 1 range affected (512 bytes)
J-Link: Flash download: Total: 0.211s (Prepare: 0.030s, Compare: 0.052s, Erase: 0.027s, Program: 0.030s, Verify: 0.024s,
 Restore: 0.046s)
J-Link: Flash download: Program speed: 17 KB/s
O.K.

And if I try to program again, the section gets skipped, because it already matches:

J-Link>loadfile c:\test\usig_src.bin 0x00C00000
Downloading file [c:\test\usig_src.bin]...
J-Link: Flash download: Bank 1 @ 0x00C00000: Skipped. Contents already match
O.K.

And immediately after programming I can read back the user signature area:

J-Link>savebin c:\test\usig.bin 0x00C00000 0x200
Opening binary file for writing... [c:\test\usig.bin]
Reading 512 bytes from addr 0x00C00000 into file...O.K.

Unfortunately, if i exit the JLink commander session and start a new one, I cannot read out the user signature area:

J-Link>savebin c:\test\fail.bin 0x00C00000 0x200
Opening binary file for writing... [c:\test\fail.bin]
Reading 512 bytes from addr 0x00C00000 into file...Could not read memory.

Because the User Signature Area is not memory mapped, I have implemented a native read function. But it seems the ramcode/applet is not loaded or used when calling savebin.
Reading works fine in J-Flash (manual > read-back > range...):

Reading target memory (0x00C00000 - 0x00C001FF) ...
 - Start of determining flash info (Bank 1 @ 0x00C00000)
 - End of determining flash info
 - Flash bank info:
 - 1 * 512 bytes @ 0x00C00000
 - Start of preparing flash programming
 - End of preparing flash programming
 - Start of restoring
 - End of restoring
 - Target memory read successfully. (512 bytes, 1 range) - Completed after 0.165 sec

Unfortunately, I really need to call this from a script, so using Jlink Commander would be ideal.
Can anyone suggest a method to read out the user signature using Jlink Commander?

Best regards,
Mikkel Holm Olsen