Bootlader single steps but resets when trying to run

[gcourtney]

I have an odd problem when trying to load and run the DS30 bootloader.
I am using MPLAB X IDE v2.10, xc16 with an IDC 3 on a dsPIC33FJ64GP706A with a 16 MHZ Xtal.
Using RS-232 and 38400 to try to program the device, but I never get that far.

I have tried to run it in several clock configurations to see if the issue is tied to the clock source or other config bits.

I believe that I have set all of the pertinent settings in the include files.

The X IDE is set to have the ASM include directories in the path. So it appears to assemble normally.

I can single step with the debugger but as soon as I let it run the unit appears to reset.
The watchdog is turned off.

The message I receive is "Target halted due to Software Breakpoint in user code"

If I try to continue from that point it goes to the mostly goes to the reset vector, or will not proceed.

If I single step at startup and then set a breakpoint for just an instruction or two further on it does not get to the breakpoint.

If I toggle an I/O pin in single step mode in the ReceiveInit loop it toggles . If I then let it run from that point no further toggling just the error message.

It something like the way an illegal opcode would act, but there are no interrupts enable and it is inline code.

It is new hardware I am working with but it runs all of the other applications I have written for it, including  simulated EEPROM which writes to the flash memory which has some mixed assembly with C.
I have two prototype modules of this design and they act identically.

I have only the bootloader in the project and no other code.

I think I must be overlooking something obvious, but after more than a day and a half without any improvement I decided to post in hopes someone has seen this issue before.

Any ideas???

[gcourtney]

I found the cause of this odd behavior and a solution for the very short term, until I can get the system to assign the initial conditions properly.
The problem is caused by the SPLIM register.
With all of the other code the compiler is assigning the SPLIM reasonable values, but with just the assembly code in the DS30, it assigns it to a number beneath the assigned stack value. Which is an error right out of the gate.
So I can either remove the assignment mov #__SP_init, WSTPTR ;done this way which the system only appears to allocate about 75 bytes.

Or use this at the beginning of DS30 loader
mov #__SP_init, WSTPTR
mov #__SPLIM_init,w0
mov w0,_SPLIM

This allocates too much, which is almost the entire memory to stack because it is just the DS30 in the project.
I will probably assign values manually in the end given what I have observed.

The red herring in all this is the way the single step would work, and the false error message of "Target halted due to Software Breakpoint in user code".
So given the stack was at a reasonable location I never noticed the SPLIM was beneath the initial value.

I hope this helps someone else.

[Mikael Gustavsson]

Thank you for the report!