Search Results

Quote from pavel4: “Hello I'm setting up a production programming where we need to flash three images per target, e.g. bootloader, configuration, firmware. This post asks a similar question but I don't think batch programming would work since the second file is not flashed from the next available address after the first file [SOLVED] Flasher Pro/Portable Standalone - Flashing multiple .hex files in to a single target I also want to avoid merging the images to a single file since one of the files…

Thanks for your feedback and the compliments. Regards Arne

Hello, I will close this thread, since you also opened a support ticket. Could you please avoid contacting us via multiple channels for the same topic? This might increase the handling time for support requests by generating unnecessary overhead. Thank you. Regards Arne

Hello, Flash memory, as it is used on the Flasher ATE, has a limited write endurance. We do not want to wear out the Flash memory by writing excessive log files. If you already have access to the TCP terminal with the detailed messages, why would you like to have these saved into a log file? Best regards Arne

Hello, the Flasher does not support "read-modify-write", therefore you'd need to create a second minimal data file which only contains the affected sector. This will be even faster than the "read-modify-write" procedure, because reading is not necessary. Best regards Arne PS: If you have additional questions, please use our technical support system: segger.com/support/technical-support/

Hello, yes, you can use multiple channels in the way you described. But every data packet has to contain data for each channel (8/12 bytes in your case). If you want to write your own application, I recommend our SDK: segger.com/products/debug-prob…nk/technology/j-link-sdk/ Best regards Arne

Hello, we are working on that. Since you get a positive result after the second programming attempt, we did not give it a high priority. Best regards Arne

Hello Tal, Could you please update the SDK? The current API provides access to CPU registers: // // API version v1.1 and higher // U32 (*pfReadReg) (U32 RegIndex); void (*pfWriteReg) (U32 RegIndex, U32 Value); For now, it should also be possible to use standard memory allocation, but we recommend to use the functions provided by the SDK. Best regards Arne

Hi Bjarne, file extensions are not to be added for universal flashloader projects, because it uses an .uni file instead of cfg/dat. So the extension .uni needs to be added to tell the flasher not to add wrong file extensions. Port 42 means the TCP port 42. Every module has a target channel on port 40+[module no.] This channel is used to get detailed information about the programming process. Regards Arne

Hi Bjarne, could you please enter the full text and not leave the extension? #select 2 flasher.uni Regards Arne

Hello Bjarne, for more details, please connect a second terminal to port 42 before #auto. At a first glance, you might have used the wrong #select command. "#select 2 flasher.uni" might work. Regards Arne

Hello Bjarne, maybe you'd need to download the recent version. Just put "24C512" into the device search mask: ibb.co/Rzvkdpd Best regards Arne

Hello, we currently do not have an API in the Flasher Portable Plus to read an IDCODE from a file. Such an API is under development, but it does not have a high priority and I cannot give you a schedule. If you are interested in a faster development for NREs, please open a ticket: segger.com/support/technical-support/ Best regards Arne

Hello Bjarne, it is possible to directly program this EEPROM using the Universal Flashloader: segger.com/products/production…e/#universal-flash-loader (24C512 should work) It is also possible to indirectly program the EEPROM, but this requires a custom Flashloader. You can develop this Flashloader by yourself: wiki.segger.com/Open_Flashloader Best regards Arne

Hello, do you have a gap in between the bootloader and the program code? If yes, could you please give us some details about the data areas (e.g. 0x0000 - 0x0800, 0xA000 - 0xC000)? Best regards Arne

Hello, the nRF52 chips have a special section called "UICR": https://infocenter.nordicsemi.com/index.jsp?topic=%2Fcom.nordic.infocenter.nrf52832.ps.v1.1%2Fuicr.html You can enable the readback protection by simply defining the appropriate register (APPROTECT) in your data file. Regards Arne

Hello, there is no new version yet, but we are going to improve the symbol name handling. Best regards Arne

Hello Michael, could you please try the current beta version v6.11m? This version has lots of improvements and should solve at least some issues. The request for a firmware update should not happen. But this is more an issue with the J-Link software. J-Scope itself does not care about firmware updates. Are you using the latest release of the J-Link software (v6.52)? Best regards Arne

You are correct, FreeRTOSDebugConfig only specifies offsets for TCB_t and not List_t. For List_t the plugin only can assume the "standard offsets", so the List_t offsets need to be added to FreeRTOSDebugConfig. FreeRTOSDebugConfig is maintained by mcuoneclipse, so you might ask there for this extension. Alternatively, you can add your own TickType_t to the end of the list while leaving a dummy 32bit entry at the original location. An additional solution might be to use our debugger Ozone. This d…

Hello Joerg, the RTOS plugins currently only supports Cortex-M architectures (0x0D31FFFF == JLINK_CORE_RX71M). If you are interested in writing your own plug-in, you can request our SDK: segger.com/downloads/jlink/#gdbserver_rtos Best regards Arne