Search Results

Hi Mark, Did you have the chance to gave the project i have attached to my previous post a try? Does it show the same issue or does it work correctly? Quote: “Is there some way to specify where breakpoints get set?” In general breakpoints should only be set to the addresses where the IDE (or the user) tells the debugger to set the breakpoints. So if EWARM tells J-Link to set a breakpoint in the heap management code, J-Link will set it there. Quote: “The other issue is that i keep seeing hardware…

Hi Levi, We received the files. Thank you for sending them. We gave it a try but we are not able to reproduce the behavior your seeing. Everything works just fine here. What we have done: - Erased the flash via J-Link Commander - Verified that the flash is empty by using the savebin command - Closed J-Link Commander - Started GDB Server with the following command line options: -select USB -device SiM3U167 -if SWD -speed 4000 (you can also just start GDB Server without command line parameter and …

Just send the file(s) to segger.com/support/technical-support/ with reference (link) to this forum thread. Best regards Erik

Hi Mark, I am sorry to hear that you run into trouble after switching from an old J-Link to a new J-Link Plus. This should not be the case and we are not aware of any issues regarding this setup. We gave it a quick try with an STM3210E-EVAL (STM32F103ZET6 on it) + IAR v6.50.6 but everything works just fine. It sounds a bit like the project is not configured correctly. Is it possible that you provide us your project? If you do not want to share it in the forum you can sent it via e-mail to https:…

Hi Levi, sounds strange. Can you please sent us / upload your *.axf file so that we can have a look at it? Best regards Erik

Hi, Can you please provide us the serial number of your J-Link? If you do not want to post it in the forum, please send it to supprt_jlink@segger.com with a link to this thread. Quote: “We are currently using a devboard made in house” Do you have a opportunity to check this on an Evalboard? We gave it a try here with an Silicon Labs SIM3L1XX-LCD Evalboard (SIM3L167 on it) and erasing, programming, reprogramming, etc via J-Link Commander works perfectly fine as you can see in the attached screens…

Hi Philipp, Good to here that the new version solves the issue. Thread is closed. Best regards Erik

Hi, From the J-Link Commander output you sent us everything seems to be fine. We gave it a second try and everything still works just fine. Please find attached the used project for a STM32F4-DISCOVERY (STM32F407VG device on it). It includes two batch files where each of them programs a small application which shows some leds blinking. The first one (Blinky_50_200.bat) shows a fast frequency blinking and the second (Blinky_400_800.bat) shows a slower frequency blinking. Can you please give this …

Hi, This behavior of course sounds strange. In general we are not aware of such a behavior so we gave it a quick try with a STM32F407 discovery board but everything works as expected just fine. Can you please describe your procedure in a very detailed way, so that we can take a look if there perhaps is anything wrong? Do you close the commander between programming the images? Do you power-cycle the target between both sessions? What commands exactly do you sent via J-Link Commander? Best regards…

Hi, Quote: “How can I use command line interface to program my image into Discovery Flash instead of using J-Flash with extra license. ” In general this can be done via the loadbin command. The loadbin command is limited to *.bin files. The latest beta version of J-Link Commander (v4.81e) comes with the loadfile comamnd which also allows downloading different data file types (*.bin, *.hex, *.srec etc...). The syntax is completely identical for both commands: loadbin <BIN_FILE_NAME> <DEST_ADDR> l…

Hi, We are not aware of any problems regarding flash programming of the SPC560P50L3. We gave it a quick try with the latest software version (V4.80f) and everything works just fine. We are able to read back / erase flash / program flash / verify flash... without any problems. I assume you are using J-Flash for your purposes? What debug probe do you use? It seems to me that the project is not configured correctly. Can you please give the attached J-Flash project a quick try and provide some feedb…

Hi, Thank you for pointing this out. We determined the problem here. We plan to create a new version of the J-Link software which includes this fix tomorrow/next week. Best regards Erik

Hi, We checked this behavior with the following setup: - EWARM V4.40.1 - IAR sample project (AT91SAM7A3-BasicTools) - J-Link DLL v4.80b - J-Link RDI DLL v4.80b - AT91SAM7A3-EK So far, we do not see any problems. Everything works just fine (we verified flash and RAM debug via RDI). Is it possible to send us your project? Maybe a trimmed version of the project so we can check if we are able to reproduce the issue? If you do not want to upload this project in this forum, you can also send the proje…

Hello, We are able to reproduce this behavior here on an MKL26Z128xxx4 board. It seems to us that the last 4 bytes of your files contain the CRC of the first 16 bytes which creates a little problem when calculating the CRC over the whole data file (the CRC of both files are exactly the same). The J-Link DLL compares both CRCs and comes to the result that they match each other. As a result J-Link DLL skips erasing/programming. Please find below a quick workaround for this issue. It shows how to c…

Hi, We have just released a new version of the J-Link software (V4.78e) which comes with a fixed version of the "J-Link STM32 Unlock" tool. This version includes support for unlocking STM32F37xx devices. The new version can be downloaded here: segger.com/jlink-software.html Best regards Erik

Hello, We are able to reproduce the issue here. We will fix it and create a new version of the J-Link software. The software is planned to be available at the end of this week/beginning of next week. Best regards Erik

Hi Alex, Sorry for not getting back to you earlier. We tried to reproduce the described behavior with the bin file you sent us. Unfortunately we are still not able to reproduce this here. Programming were successful in 100% of our test cases. We do not see any differences between your and our test environment. Please understand that it is a bit difficult for us to investigate such behaviors without being able to reproduce it. Best regards Erik

Hi Alex, We tried to reproduce this issue with an identical setup (provided J-Flash project, J-Link Ultra+, V4.74a, etc...). We used an EFM32TG840F32 instead of an EFM32TG210F32 because we do not have such a device in house. However this should not make any differences since both devices are handled identical by J-Flash/J-Link DLL. We reprogrammed our device about 300 times but so far we are not able to reproduce this behavior. What OS are you running on? Does you see this behavior only when usi…

Hi Henry, We tried to reproduce this here but everything works just as expected. We used the latest official version of J-Flash ( v4.68 ) + SAM7SE-EK (SAM7SE512 on it). Please find attached the project we used (forum.segger.com/index.php/Att…1a52fe5b51fc050253af6f59b). Could you please give it a short try? Does it work? Or do you still see the same behavior? As Alex already wrote before, please notice that the board has to be power cycled after programming in order to secure the device. Best reg…

Hi, What target device do you want to secure? The "Secure chip" option supports only some devices (e.g. STM32). In general J-Flash offers the opportunity to configure so called "Exit steps", which are performed immediately after the target has been successfully programmed. The exit steps can be used to do some special handling after programming, for example to set the security bits in order to secure the chip. You find the "Exit steps" in the "Project settings" -> "CPU" tab -> "Exit steps". Best…