Sparrow_Altera
Occasional ContributorJoined 10 months ago
User Profile
Occasional Contributor
User Widgets
Contributions
Re: eCoS OS throws execption when freeing memory
You may have a possible heap corruption based on the stack trace. The fact that the allocation just before this succeeds, but free dies, fits with heap corruption: malloc didn’t happen to touch the damaged area; free did. Heap metadata is corrupted or the pointer/size you’re freeing is not consistent with how it was allocated. Things you can check: Size mismatch between alloc and free: Confirm that the size used for allocation and the size passed into vf_free_buffer() are always identical. Buffer overrun/underrun before the 7th free: If bytes_to_copy exceeds either the old or new allocation size, you write -> That trashes the allocator’s metadata. dlmalloc stores control info just before/after the user block; once that’s corrupted, the next free() can blow up. Check all memcpy, memmove, memset, and loops that touch this buffer. Double free or freeing a modified pointer: After vf_free_buffer(), always set the pointer to NULL. Make sure there’s a single owner of this buffer; no multiple modules freeing it. Using the buffer after freeing: If your “resize until bigger” logic lives in this area, it’s easy to do: Allocate buffer, Use buffer, Decide you need a bigger buffer → allocate new, free old. But something still holds a pointer to the old buffer and writes into it while or after it’s freed. This again corrupts heap metadata, shows up in a later free(). Ensure that all users of the buffer go through a single handle. Whenever you resize, update that handle everywhere before any further writes. Memory layout / stack overlap: If stack or some other buffer overwrites the heap region around 0x017136A0, dlmalloc will die on free. As a sanity check: Temporarily skip resizing logic Change the code to allocate a large enough buffer once, then use it without freeing/resizing in the loop. Keep all the same write/copy logic. If the exception disappears: The problem is very likely tied to how you’re managing allocations (size mismatch/double free). If the exception still occurs: The bug is almost certainly a pure buffer overrun/underrun in your write logic, independent of malloc/free.Re: Agilex 5 EMAC to EMAC : Driver error
Hello K606 As you wait for the sof file analysis to come back, you can check the below information that one of my colleague shared For a MAC-to-MAC loopback test, it requires additional logic. The main logic that enables this is: fyi, this code above has not gone thru validation, but my colleague has tested the basic functionalities (ping and iperf transfers). The DTSI is correct. But additional kernel option (network namespace) needs to be enabled to ensure the data transfer is not virtual. This is because Linux network stack is pretty intelligent to detect transfer between interfaces on the same host and will attempt SW transfers without going thru MAC. ThanksRe: max10 remote system update nios with uart
Hello Nios II is EOL, Altera stop selling Nios II/f license. New users need to migrate to Nios V and apply the Nios V license. Regarding the example design, couple of points below that can help you. To simplify the design, it can be divided into three function blocks: RSU block (Dual Configuration IP to handle RSU) UART block (Communication thru UART) Booting block (Nios to boot from QSPI) RSU block (Dual Configuration IP to handle RSU) UART block (Communication thru UART, such as printf & scanf) Booting block (Nios booting from QSPI) Below User Guides will help you to understand more about these function blocks. RSU block (Dual Configuration IP to handle RSU) MAX® 10 FPGA Configuration User Guide (How does Dual Configuration IP handle Max 10 RSU?) MAX® 10 User Flash Memory User Guide (Dual Configuration IP switches the target CFM only, you will need On-Chip Flash IP to change the FPGA Image in CFM) UART block (Communication thru UART) UART Core (Altera HAL driver to send/receive UART data in Software Programming Model subchapter) Booting block (Nios booting from QSPI) Nios® II Processor Booting from QSPI Flash (QSPI Controller + OCRAM is a must to boot Nios II from QSPI) Nios® V Processor Booting from General Purpose QSPI Flash (QSPI Controller + OCRAM is a must to boot Nios V from QSPI) And finally connecting the 3 logic blocks to get the whole design, ThanksRe: max10 remote system update nios with uart
Hello Can you check your design settings in Quartus with the example design settings, the link below provides the file for the example that you are trying to follow Intel® MAX® 10 FPGA – Intel MAX 10 FPGA Remote System Upgrade (RSU) over UART for the Nios® II Processor Design Example Thanks
