Honored Contributor
Honored ContributorAmusing. Now that we've gotten everything hooked where it belongs, I find that the initialization is copying 0xffffffff's from a bad location to where the data is actually at (that is, from __flash_rwdata_start to __ram_rwdata_start when ram_rwdata has the correct data and flash_rwdata is in nonexistent area). This has a tendency to really mess things up :-).
I used the 'jump' debugger command to not execute any of those alt_load_sections in alt_load, and now I discover that 512 - 1 equals 33489407 (or 0x01ff01ff - hmm, 512 is 0x200 - probably not a coincidence) when inside of OS_TaskStkClr at line 1082 where it subtracts 1 from size. Very strange. In fact, if I set size to 511 in the debugger and then print it, I get it duplicated like that. (that is, if I set size to 0 and print it, it is a zero, but if I set it to 512 I get 0x1ff01ff). And if I try to cheat and jump over the stack zeroing I find the program executing (after a while and after I hit control-C) at 0x5c77a74c, which is to say nowhere valid. I'm going to go try to get the FPGA and the program to work together to the point that I'm not debugging '0x1ff == 0x1ff01ff' issues and I'll post here once I'm past the weird stuff. I *expect* that now that I've got sgdma and ddr and tse all hooked together in the FPGA right (and I use the correct addresses in the descriptors (and the descriptors I use are actually in the descriptor memory)) - well, then I have half a hope of DHCP being able to send a packet... Thanks - I'll be back in a while with an update (I hope!)
