Hi, Mark.
>>As for the DMA problem, at least when running using the debugger, the code appears to hang
Are you sure that the watchdog is disabled when debugging? - otherwise it fails when breaking and trying to step.
I have never disabled the watchdog while debugging, and I've never had a hanging problem. The only strange and annoying debugging behavior that I regularly see is that serial communication never resumes once the first breakpoint has been hit. I've never bothered to try to figure out why, since if I'm single stepping, I am not usually making much use of the debugging data that I send out through the serial port.
To this, I must now add that further experimentation with uMemcpy() has shown the following weird debugger behavior that occurs if I single step through fnFlashNow() and then examine what is in RAM when fnRAM_code() is called. If I do this the first time fnFlashNow() runs, it will not copy the fnRAM_code() routine into RAM, as I have already reported. This happens even when the actual copy from FLASH to RAM is run at speed using run-to-cursor or some other way of executing the copy instructions. However, if fnFlashNow() runs once before I hit a breakpoint, the necessary code is copied into RAM. I confirmed this by adding two calls to fnSaveNewPars(SAVE_NEW_PARAMETERS), one right at the end of fnApplication() and another in my own routine that is called later. If I wait until the second one is called and single step through fnFlashNow(), the fnRAM_code() routine has indeed already been copied to RAM. This tends to confirm your comment
Therefore my assumption is that what you are observing has something to do with the operation of the debugger.
I will send you the requested copy of SP6 that hasn't worked with version 7.0 of the IDE in the next few minutes. If you look in uTaskerSP6\Applications\uTaskerV1.3\CodeWarrior_M5223X\uTaskerV1.3, you'll find a .png file that captured the various updates that took place when first run under version 7.0 of the IDE.
Right now, I'm trying to figure out the maximum size that the PARS structure can have. From the documentation, I thought the calculation would be 2046 Bytes (FLASH_GRANULARITY - 2) diminished by the size of the NETWORK_PARAMETERS structure (24 Bytes), leaving a total of 2022 Bytes for PARS. However, my experiments have shown that if its size is 704 Bytes, then shortly after I call fnSaveNewPars(SAVE_NEW_PARAMETERS), my program hangs completely -- so completely that I have to unpower the DEMO board and restart the IDE to again communicate with the board, even to erase its memory. If its size is reduced to 272 Bytes, the program runs just fine. (I find the size by disassembling application.c and then looking at the Section Size associated with _cParameters. I have confirmed by setting breakpoints that this is the same size that's sent to fnSetPar().) Of course, the problem could be elsewhere. For example, I might be overlaying fnRAM_code() with the longer parameter blocks.
As you can tell, I'm still experimenting with parameter blocks.
Best regards,
Richard