Network Debugging issues

[rdb9878]

I'm having trouble getting network debugging to work with MOD5272. I've seen it work fine at least once, so I know it's doable, but as I sit here now I am stuck in the mud. Here are some issues I've seen:

1) After starting debugger, the progress bar stays at 0 until I get a "timed out" message. At this point, my app in flash gets corrupt. I see the boot menu "Waiting 2sec to start 'A' to abort," on the serial port but not the usual stuff that my app prints out on startup. I have to painstakingly reflash the NB via my eval kit serial port because the app never loads...very annoying when the netburner is hard to get to.
2) After starting the debugger, the progress bar goes to 100%, the perspective changes to the debug perspective, but my breakpoint near the start of the code (after initialization) is never hit, and I'm stuck on a screen that says "No source available for """. Other than this, my app appears to be working fine...I even verified that the app was getting uploaded correctly by changing a version string.
3) After starting the debugger I can step through the code somewhat, but after a few steps the code just seem to run and I'm not hitting any breakpoints anymore....

As for my IDE setup, it's a "NetBurner Launcher" configuration with target IP matching my NB, Debugger is "NetBurner Standard Debugger", I've tried stopping on main as well as just unchecking the box to stop on main. GDB debugger command says "m68k-elf-gdb", GDB command file is blank, Protocol is "Default", Reboot time is 10 seconds, connection type is TCP with hos name matching the IP address of my NB, port number 2159.

Any suggestions?

[rnixon]

I would recommend running the module in the development board and following the tutorial in the debug section of the eclipse manual (in docs directory). Everything needs to be correct to debug. You might have some settings off.

Network debuggers take time to connect. So a breakpoint right after the initialization will never work. If you want one there set an OSTimeDly( 2 * TICKS_PER_SECOND);, and set a breakpoint AFTER the timeout. Make sure this is also after you get a dhcp address if your using dhcp.

The app corruption is a cause for concern. The debugger shouldn't be able corrupt your code. Somehow your app or h/w has a problem. Are you writing to the User Parameter or System Parameter Config space in flash? Does your h/w connect to the module's address or data bus? We had an issue in which we were connected to an fpga that drove those lines when it should not have, and corrupted flash during the programming cycle.

[rdb9878]

The app reads from the User Parameters on startup, but it's very rare for it to write to the User Parameters at all (and definitely not on startup)

We do have a FPGA connected to the data bus which should stay in a high-impedance state until the chip-select is enabled,

Code: Select all

sim.cs[1].csbr = BASEADDRESS | 0x201;
sim.cs[1].csor = 0xFFFFF028;

With a base address of 0x30000000 (where could I find a NB memory map?). Not sure why the original coder configured it to so have many address-mask bits set in the csor register when the external address bus is limited to 16-bits...

Also, there are no pull-up resistors on the chip-select signal in our HW. I couldn't find any description of whether or not the processor/netburner itself has internal pullups on the chip-select pins...maybe the CS pin is in an active-state after a reset?

[rnixon]

In my experience it doesn't matter what the fpga "should" be doing. What matters is what it is doing. If you have corruption there is a 99.99% chance its not doing what it should be doing. Easy to test. Either remove it from a board and run a bunch of tests looking for the same behavior (best choice), or, try programming it to do nothing but tristate all pins. It took that level of proof to convince the fpga code designer in our case. Once the fpga design was reviewed, what do you know, there was a set of conditions that would drive the lines when it should not. There can be a LOT of test cases for a fpga design. Using the autoupdate shutdown hook callback function in the netburner enabled us to command the fpga to a safe state before a flash update was performed and the problem was resolved.

Look in your nburn\docs\platform directory for hardware specific things such as the memory map

[rdb9878]

lol! Don't worry, I am not in FPGA/HW design denial! Just looking for possible cause/solutions/suggestions (thus me questioning things like "Do I need an external pullup on the CS pin?").

I will definitely heed your advice and start small scale with the eval kit and the tutorial, and work my way up to final system. Thanks!