Search Results

Search results 1-20 of 28.

This site uses cookies. By continuing to browse this site, you are agreeing to our Cookie Policy.

  • Ozone V3.10g with a bootloader elf file crashes if Debug.Halt(); occurs after it leaves the bootloader section of memory. On another device and with a different bootloader, this does not occur using Ozone. The SEGGER J-Link Pro and Ultra+ are being used as debuggers. The targets are STM32F4. Cheers, Joe

  • Changing to "Autostart local GDB server" from "Connect to remote GDB server" appears to help in some cases. However, it appears that GDB periodically becomes unstable, unresponsive, and the session becomes corrupt. How can I gain more insight into the GDB communications between SEGGER GDB Server and the IDE?

  • 1) SEGGER J-Link GDB Server takes an elf file and flashes the target device. 2) J-Flash takes a hex file generated from the elf file and flashes the target device. J-Flash verifies the (1) scenario as a different checksum than if it were to flash the hex file itself. Similarly, GDB will compare and reflash if the J-Flash hex file (2) had been flashed previously. How can I find the differences? A bit about the hardware platform: It has a bootloader and application binaries. The application has ac…

  • I am using Atollic TrueSTUDIO for STM32 9.2.0 with the latest JLink for windows. When I go to program the device with the project .elf file via gdb, it hangs. This behavior has been occurring more frequently with later updates. I launch the JLink GDB server with a windows shortcut: Shell-Script (1 line)The logs indicate that it has flashed the device and no errors or problems that I can see. Breakpoints are enabled for main. Any thoughts on where else I can look to see what is hanging? Cheers, J…

  • Greetings, Thank you for Ozone! I feel like I am working with a computer again! It is refreshing! A quick feedback: The editor does not properly parse "\\" for color. For example: Source Code (2 lines) Keep up the good work! =) Cheers, Joe

  • Fabian, Thank you kindly for your reply. It led me to double check my terminal, which was the issue. The Winsock was in telnet rather than raw mode. I was using RealTerm telnet Hex(space) Display mode. and the code was C Source Code (20 lines)Cheers, Joe

  • I am playing with SEGGER RTT and it is pretty nice so far. I was testing its ability to do binary, which it handles very well until character 0xff. This appears to be an escape character of sorts. It outputs occasionally and sometimes consumes the next byte. What does it do? SEGGER_RTT_PutChar(0, 0xff); Cheers, Joe

  • Hello, Upon ESTABLISHING the first connection to 19021, the RTT server spawns another LISTENER for 19021: Quote from First RTT Client: “C:\cmder λ netstat -aon -p tcp | findstr 19021 TCP LISTENING 1268 C:\cmder λ netstat -aon -p tcp | findstr 19021 TCP LISTENING 1268 TCP ESTABLISHED 1268 TCP ESTABLISHED 10900 ” Connecting to that LISTENER can occur. A new LISTENER is spawned, but i…

  • Hello, I am trying to get the --autoconnect feature of JLinkRTTViewer.exe to launch the viewer and start a new connection over usb like so: Shell-Script (1 line) When I launch the above command, the window briefly appears then the application exits with error code 9009 (echo %ERRORLEVEL%). Without --autoconnect works but with the dialog for setting up the device. Serial number is the right one (tested with JLink.exe). Version is V6.46.d. How can I get RTT Viewer to launch from command line witho…

  • GUI_alloc errors in Simulator

    jhgorse - - emWin related


    Manually detaching and deleting the DATA objects appears to resolve the issue. As seen here: GRAPH free allocated memory problem. How do other folks go about doing this as they switch between screens? The updated code resolving the errors, for completeness: C Source Code (121 lines)

  • GUI_alloc errors in Simulator

    jhgorse - - emWin related


    Using the code below and clicking the Home button which performs GUI_EndDialog(pMsg->hWin, 0); we will get MAX_GRAPHS (3) of these "GUI_alloc.c: block to be deleted already locked in _Free()" errors and 1 "GUI_alloc.c: GUI_ALLOC_h2p: illegal argument (0 handle) in GUI_ALLOC_h2p()." error. The question is, what is the best practice for cleaning up a graph window? Cheers, Joe Referencing threads: GUI_alloc erro GRAPH free allocated memory problem. C Source Code (113 lines)

  • Resolved by moving the emWin RAM to SDRAM and increasing it from 100 kB to 1,000 kB.

  • Greetings, I am looking for ways to optimize the performance of the GRAPH_DATA_XY widget for the refresh of the screen for new data on embedded hardware. The vertical refresh is progressively slower the more data is displayed (# of chart graphs, primarily). I have an STM32F429ZI running with external 32 MB SPANSION SDRAM on an 800x480 LCD. WM_SetCreateFlags(WM_CF_MEMDEV) is set before GUI_Init(). I believe I have triple buffering on now which helped with screen flicker between emWin screens prev…

  • It is actually working. My color scheme has the same color for the first two graphs, so I did not see it. Cheers.

  • The first graph displays, but the second graph does not. This can be observed on embedded hardware and the PC. As I converted this to a test case, the PC version stopped showing secondary graphs. I have not caught that bug yet. In the larger project this had worked on the PC, but not the embedded side. Here is the code: C Source Code (225 lines)

  • Greetings, Previous I have used the blocking call to GUI_ExecCreatedDialog(hWin) and the GUI_EndDialog(pMsg->hWin, retval) within the FrameWin to come back to the master state machine which controls which screen we are on. Now I need to run it as a non-blocking call, e.g. GUI_Exec1(), and refactor the detection of the EndDialog() condition. I have played with the API a bit and I have not come up with anything useful. I thought WM_ForEachDesc() might be a good way to explore the existing windows,…

  • Jörg, I have run the test pattern. It appears as expected. I suspect it had to do with anti-aliasing or the memory-mapped lcd driver. In any case, using non anti-aliased fonts seems to be working. Cheers, Joe

  • I never debugged the entire issue. I disabled antialiasing on the font conversion and the red bands have disappeared. I assume it had something to do with the blending which was occurring.

  • I am seeing some discoloration of externally generated latin fonts in a horizontal band through the middle of the screen. The black text appears red-ish in the band. See the attached images. The latin fonts were converted with 4bpp anti-aliasing while the Japanese font was not. These red bands do not appear when using the default emWin latin fonts. Any thoughts as to what may be causing this?

  • The answer is to remove C Source Code (1 line)