Lab 5: System Initialization
5 - 26 TMS320F2837xD Microcontroller Workshop - System Initialization
EMU_BMODE values from the PIE RAM. These values were previously set for boot to
RAMM0 boot mode by CCS. Since these values did not change and are not affected by
reset, the bootloader transferred execution to the beginning of our code at address
0x000000 in the RAMM0, and execution continued until the breakpoint was hit in main( ).
Run the Code – Watchdog Reset Enabled (Hardware Reset)
18. Open the Project Explorer window in the CCS Debug perspective view by selecting View
Project Explorer. Modify the InitWatchdog() function to enable the
watchdog (WDCR). This will enable the watchdog to function and cause a reset. Save
the file.
19. Build the project by clicking Project Build Project. Select Yes to “Reload the
program automatically”.
Alternatively, you add the “Build” button to the tool bar in the CCS Debug perspective (if
it is not already there) so that it will available for future use. Click Window
Perspective Customize Perspective… and then select the Tool Bar Visibility
tab. Check the Code Composer Studio Project Build box. This will automatically select
the “Build” button in the Tool Bar Visibility tab. Click OK.
20. Again, place the cursor in the “main loop” section (on the asm(“ NOP”); instruction line)
and right click the mouse key and select Run To Line.
21. This time we will have the watchdog issue a reset that will toggle the XRSn pin (i.e.
perform a hard reset). Now run your code. Where did your code stop? Why did your
code stop at an assembly ESTOP0 instruction in the boot ROM at 0x3FE493 and not as
we expected at the breakpoint in main( )? Here is what happened. While the code was
running, the watchdog timed out and reset the processor. The reset vector was then
fetched and the ROM bootloader began execution. Since the device is in emulation boot
mode, it read the EMU_KEY and EMU_BMODE values from the PIE RAM which was
previously set to RAMM0 boot mode. Again, note that these values do not change and
are not affected by reset. When the F28x7x devices undergo a hardware reset (e.g.
watchdog reset), the boot ROM code clears the RAM memory blocks. As a result, after
the bootloader transferred execution to the beginning of our code at address 0x000000 in
RAMM0, the memory block was cleared. The processor was then issued an illegal
instruction which trapped us back in the boot ROM.
This only happened because we are executing out of RAM. In a typical application, the
Flash memory contains the program and the reset process would run as we would
expect. This should explain why we did not see this behavior with the CCS CPU reset
(soft reset where the RAM was not cleared). So what is the advantage of clearing
memory during a hardware reset? This ensures that after the reset the original program
code and data values will be in a known good state to provide a safer operation. It is
important to understand that the watchdog did not behave differently depending on which
type of reset was issued. It is the reset process that behaved differently from the different
type of resets.
22. Since the watchdog reset in the previous step cleared the RAM blocks, we will now need
to reload the program for the second part of this lab exercise. Reload the program by
selecting:
Run Load Reload Program