- Q: What is the difference between the TMS320F28xx and the TMS320C28xx MCUs?
A: The "F" represents flash, while the "C" represents ROM. The Flash devices are reprogrammable and are available through normal distribution channels to mass market customers. The TMS320C2812 is a custom ROM device and typically will only be released in TMS version, and will not be released in TMX or TMP versions. For ROM devices the customer provides their source code and TI actually factory program the source code in the ROM memory. When the code has been finalized, the code can be submitted to Texas Instruments for masking into the on-chip program ROM.
- Q: What does the term "atomic operations" mentioned in C28x documentation refer to ?
A: Atomic operations are operations that cannot be interrupted. On C28x devices Atomic operations perform Read-Modify-Write operations on any memory (both on-chip and external) or register location in a single cycle without being interrupted. The atomic operations reduce code size.
- Q: Where can I find example programs in C to initialize and test peripherals on C28x devices?
A: Please download "C28x Peripheral Examples in C (SPRC097)". Unzip the files to its own directory. You can find many example programs in the DSP28/examples/sub directory.
- F24x & LF240x Based Device
- Q: Can I perform floating point operations on TMS320C24x DSP?
A: It is advisable not to perform floating point operations on the C24x. You can use the floating point compiler RTS library functions, however it will be very very slow. There is no IQmath library for C24x devices. Even 32-bit Q-math would be inefficient on C24x, as C24x CPU and the bus are just not designed to do 32-bit operations efficiently.
- Q: Do the F24x and F240x DSPs have the boot loader already loaded into the chip?
A: The F24x device as shipped from the factory has the serial boot loader programmed in the flash. For F240 DSPs,it is located between the flash locations 0x3E00 to 0x3FFF. For F241/F243 DSPs, it is located between 0x1F00 and 0x1FFF. The user code must not use the program space allocated for the serial boot loader in these devices.
The F240x and F240xA DSPs come with the boot loader programmed on Boot Rom that is separate from the flash and is located between the program spaces 0x0000 to 0x00FF. The Boot Rom and Flash Memory appear in the same memory space and hence are not active at the same time. If BOOT_EN*/XF pin is LOW at reset then flash memory is disabled and Boot Rom is enabled.
- Q: If I delete the boot loader in the flash on F24x and F240x devices, will I be able to program it back into the flash sector of the chip?
A: The TMS320F24X devices are shipped with the Boot Loader programmed into the flash. When performing the flash operations, the entire flash array is cleared, erased, and re-programmed. This means that the Boot Loader is erased from the flash. In case of the serial port flash programming utility, the Boot loader is re-programmed into the flash. In case of the JTAG utilities, or if the serial port programming terminates before completion, then the Boot Loader is lost. In such cases the JTAG tools must be used to restore the utilities.
The TMS320LF240X devices have the Boot loader in ROM (Read Only Memory). This cannot be deleted.
- Q: Can I use the F240x flash tools from TI web site to program an external flash EEPROM?
A: The F240x flash utilities found on the TI website are for programming the on-chip FLASH memory of 240x DSPs only. They cannot be used to program external flash memory chips.
- Q: Can I flash F24x or F240x DSPs from an external peripheral?
A: Yes. You can flash F24x and F240x DSPs from an external peripheral by using SCI or SPI port on the DSP.
- Q: Do the 24x/240x devices support BSDL?
A: No, the 24x/240x family of DSPs do not support BSDL, as mentioned on the Datasheet.
Flash- Q: What programming options are available for the TMS320F28xxx devices?
A: There are several options available for programming the flash of the TMS320F28xxx devices. These range from JTAG, serial, embedded, and production solutions. The tools for these options are consolidated and discussed in the Flash Programming Solutions for the TMS320F28xxx DSCs (SPRAAL3) Application Note.
The on-chip flash memory on the C28x devices can be programmed via JTAG or SCI serial interface. For JTAG, there is the Code Composer Studio (CCS) flash plug-in and SDFlash, a standalone utility from Spectrum Digital. Blackhawk also offers a standalone tool, BhFlashBurn, in both scriptable, command line and GUI forms. The CCS flash plug-in can be downloaded from the Update Advisor, CCS->Help->Update Advisor...The SDFlash GUI interface and algos(rev. dependent) can be downloaded from our C28x Flash Tools link provided below. For serial interface, there is the SdFlash v1.60 Beta patch from Spectrum Digital. The patch is also available from the C28x Flash Tools. Finally C28x Flash API is available to integrate flash programming into your application. This method can enable field re-programming for firmware updates or calibration data storage. The Flash API can also be downloaded from the C28x Flash Tools.
- Q: Are there any flash examples or an application note that describes how to convert my project from RAM based to flash based?
A: The Running an Application from Internal Flash Memory on the TMS320F28xx DSP(SPRA958) Application Note describes the different aspects of converting a program from RAM based to flash based. Examples are also provided with with app. note to demonstrate the procedure and give a template to begin.
- Q: Can I program Flash or OTP (One Time Programmable memory) on C28x devices incrementally such as one word at a time?
A: Yes. You can program Flash and OTP on C28x devices incrementally one word at a time. As a matter of fact, you can program as little as a bit. For example, you can program bit 0, and then later program bit 1 within single word. This is because in order to protect the flash, the algorithm will not attempt to program a bit that is already programmed. So for example, you can program 0xFFFE (program bit 0) and later program 0xFFFC (program bit 1). In the latter case the algorithm will recognize that bit 0 is already programmed and only program bit 1. Just remember, the program operation can never bring a 0 back to a 1 and that the OTP cannot be erased.
- Q: When attempting to use the On Chip Flash Programmer within CCS, I receive an error message of Non-Supported Part ID. What does this message mean and why do I receive it?
A: The current version of the On Chip Flash Programmer does not support the device you are attempting to program. This programmer will need to be updated to obtain the newer algorithms. The updates are available in the latest Service Release and Chip Support Package available for Code Composer Studio. Updates are available with a valid subscription through the Help Menu of Code Composer Studio.
If this is the eZdsp version of CCS that was shipped with the F28335 eZdsp, it was compiled with an older version of the Flash Programmer that does not support the newer revisions of silicon. Spectrum Digital has updated this software. Please be sure to uninstall your current version first, then download the new image and install: http://support.spectrumdigital.com/ccs33/eZdsp28335_Release030320B/
- Q: When I attempt to program the flash with the On Chip Flash Programmer within CCS, I receive an error that stated Target Halted During Flash Operation. What is this error and why do I receive it?
A1: This is due to the limitation that no breakpoints can be set when attempting to use the plug in. If a breakpoint is set, you will receive "Flash API Error #14" or "Target halted during Flash operation", Flash operation aborted message. In order to clear these messages and continue flashing, all breakpoints must be disabled. To disable any breakpoints, navigate within CCS to Debug -> Breakpoints and select Remove All. This also prevents the Perform Go Main Automatically option from being enabled. This can be disabled by navigating within CCS to Option -> Customize -> Debug Properties. In this tab, ensure that the Perform Go Main Automatically option is disabled.
Once this is complete, please attempt to program the flash with the Flash Plug In. If you still receive the error, please restart CCS and attempt to program the flash before performing anything else to ensure no breakpoints are set.
A2: I was encountering this problem when trying to program a 28335 Delfino using the On-Chip programmer. A note on the "Iran DSP Center" web site provided the solution - under the menu "Options", select "Customize" and make sure the "Perform go Main automatically" is NOT checked.
- Q: When programming the flash with the CCS On Chip Flash Programmer, the following warning is generated:
What does the message mean and how can I clear this?
A: This means that there is an initialized section that is assigned to the RAM area. This is fine while the power and JTAG is connected but once power is removed, RAM data is lost preventing proper execution when executing standalone. The .cmd file needs to be checked to ensure that all initialized sections are assigned to flash. Section 3 of the Running an Application from Internal Flash Memory on the TMS320F28xx DSP
(SPRA958) App. Note explains where each compiler generated section should be allocated.
This message can be seen when at least one section that is designated to LOAD to flash but RUN from RAM in your .cmd file (which is normal for a proper flash setup). The warning is normal, and can be safely ignored as long as all initialized sections have been verified to be allocated to flash mentioned above. DSP/BIOS projects will generate this warning as well due to a couple of data sections being assigned to the RAM. In this case the message can be ignored as well.
- Q: Why do I need to set the On Chip Flash Programmer Settings everytime I restart CCS 3.3?
A: In CCS 3.3x, the settings are only retained within the same CCS session. In other words, you can close and open the Flash plugin multiple times within the same CCS session and it retains the setting. However, with each new session of CCS, it prompts for these settings again.
In CCS v4 the interface is quite different and there is a option to retain the Flash programmer settings. The Flash settings are available from the CCS Debug Perspective after Launching the TI Debugger and opening menu Tools->On-Chip Flash. This opens a On-Chip Flash view which has all the Flash settings. There is an option there to "Remember My Settings" which will preserve any changes made to the Flash settings.
- Q: How do I view/set the On-chip Flash settings in CCS v4 before programming the device for the first time?
A: In CCSv4, when a F28xx Flash based project is debugged using "Debug Active Project", the Flash settings can be seen/modified from the Debug Perspective menu Tools->On-Chip Flash. However, this menu is not visible prior to debugging the project.
In order to view/modify the on-chip flash settings prior to programming for the first time, please follow these steps:
In the C/C++ perspective, from the C/C++ Projects view, select the target configuration file (.ccxml), right-click on it and select Debug As->Debug Session. This will launch a debug session for that target configuration and switch to the Debug perspective and the On-Chip Flash menu will be visible.
Alternately, in the C/C++ perspective, from Target Configurations view, select the desired target configuration file (.ccxml), right-click on it and select Launch Selected Configuration. This will launch a debug session for that target configuration and switch to the Debug perspective and the On-Chip Flash menu will be visible.
- Q: Using the C28x On-Chip Flash Programmer plug-in to program to flash generates a pop-up message: “File Not Found: Flash_API_Interface.c Would you like to locate this file?”
A: This message always pops up when using the C28x On-Chip Flash Programmer. There is no need to search for this file. Simply press the No button. The check box “Do not show this message again” can be checked so that the message does not appear again. Please note, however, that the Flash erase, clear, or program process should not be stopped because of this error. If the flash process is terminated before completion, it can leave the flash in an unknown state or corrupt the sectors in flash memory. A workaround to not make the pop-up message appear is to turn OFF a CCS option. The procedure is as follows:
1.
Select the Option -> Customizemenu item.
2.
Under the Editor Properties tab, deselect the checkbox for the “Enable file browse while debugging” option.
- Q: Why are all options within the CCS On Chip Flash Programmer greyed out?
A: When all of the options are grey within the Flash Programmer, this means the Code Security Module (CSM) is secured with a password. In this case the only option available would be Unlock. See CSM section for information on why the CSM is secure.
- Q: When programming the flash of the TMS320F2833x/F2823x devices with the CCS On Chip Flash Programmer, some GPIOs are pulled low which leads to the potential for damage with external hardware. Why is this happening and how can it be fixed?
A: The XINTF pins are muxed with the GPIO pins. After reset these pins are configured for GPIO inputs until the application code changes this. Before loading application code to external memory through the XINTF pins, the GPIO configuration must be changed to XINTF functionality. To remedy this the XINTF_Enable function was added to the OnPreFileLoaded() GEL function in the device gel file used by CCS. This will enable the XINTF pins when the OnPreFileLoaded() function is called.
This presents an issue when programming the flash within CCS. The OnPreFileLoaded() function enables the XINTF functionality which can toggle the state of the GPIO pins. This can cause an issue for external hardware if proper care is not taken.
A simple fix for this is to open the device gel file, comment the call to XINTF_Enable in the OnPreFileLoaded() function. This will of course need to be uncommented when a project is to be loaded directly to the XINTF.
- Q: Why is the following the error message generated,"Flash API Error #21 The Erase operation failed the precondition step" while using the CCS flash plugin?
A: The most likely cause of this error is accidently stopping the flash erase process before it successfully completes. The error indicates a bad sector or sectors in flash memory. Verify the bad sector(s) by performing the following to avoid using them.
1.
Invoke the flash plug-in, CCS->Tools-> On-chip programmer.
2.
Perform the erase operation only on all the sectors. You should see the same error.
3.
Perform the erase operation only on each individual sectors. By performing this, you should see which of your flash sectors are bad.
- Q: Why am I receiving the error "Flash API Error #14 Target halted during Flash operation" while trying to program the flash using the flash plugin?
A: This is due to the limitation that no breakpoints can be set when attempting to use the plug in. If a breakpoint is set, you will receive "Flash API Error #14" or "Target halted during Flash operation", Flash operation aborted message. In order to clear these messages and continue flashing, all breakpoints must be disabled. To disable any breakpoints, navigate within CCS to Debug -> Breakpoints and select Remove All.
Once this is complete, please attempt to program the flash with the Flash Plug In. If you still receive the error, please restart CCS and attempt to program the flash before performing anything else to ensure no breakpoints are set.
Note: You must also turn off "Perform go Main automatically" under "Option/Customize/Debug Properties" otherwise a breakpoint will be inserted when you attempt to execute the On-Chip flash operation.
- Q: Does the CCS Scripting Tool support the On Chip Flash Programmer?
A: CCS v4 does support scripting for the On Chip Flash Programmer through the DSS (Debug Scripting Server). More information about this is available in the index.html link provided in the C:\Program Files\Texas Instruments\ccsv4\scripting\docs\DS_API directory after installing CCS v4. Simply scroll to the Flash topic on this page.
CCS 3.3 and earlier does not support scripting for the On Chip Flash Programmer.
- Q: Is there an application note describing how to perform EEPROM emulation using the flash?
A: Yes, please see EEPROM Emulation With the TMS320F28xxx (sprab69).
- Q: My program runs correctly when debugging within CCS but when I attempt to run this standalone it does not work. Why is this occurring?
A: This can occur for a few different reasons:
1.
The boot mode selection is not "jump to flash". Check the boot ROM guide and data manual for the particular device.
2.
There are initialized sections allocated to load to RAM instead of flash. All initialized sections should have their load addresses allocated to flash so they can be programmed. The .cmd file needs to be checked to ensure that all initialized sections are assigned to flash. Section 3 of the Running an Application from Internal Flash Memory on the TMS320F28xx DSP(SPRA958) App. Note explains where each compiler generated section should be allocated.
3.
If the code is time critical and needs to be run from RAM, it can be copied at runtime.
4.
After you copy critical sections to RAM, make sure the copy really occurred - check the memory contents.
5.
Try running the flash to RAM copy routine first. Some early functions may assume parts have been copied to RAM. For example, the delay function is used in the InitSysCtrl() function. This delay function is by default allocated to the functions TI's examples copy to RAM. If InitSysCtrl() is called before the copy to RAM then an exception will occur. TI is working to add comments to help avoid this pitfall. This also occurs with InitAdc().
6.
An instruction was not added to branch to the beginning of application code at the flash entry point. This is discussed further in Section 6 of SPRA958.
7.
281x specific: In addition to the actual boot pins, the MP/MC pin needs to be pulled low to enable the boot ROM.
To debug this issue, step through the code and try to determine where it is going wrong. Here are some debug suggestions:
1.
Flash the device
2.
Turn off the power
3.
Connect CCS and select "load symbols" only
4.
Place a breakpoint at the entry point to flash
5.
Reset the part with the debugger and run - did you hit the breakpoint? If so the boot mode looks ok
6.
Step the code until you find an issue.
- Q: Why does it take sometime for the erase operation and why there is a variation in the flash erase time for each run and for different parts? What is the maximum time for erasing?
A: The Flash erase/program operations are quite different from Flash-read or RAM read/write operations. They can not be counted as ‘fixed number’ of CPU cycles. This is due to the nature of flash process. The erase operation has 4 steps as below:
1.
Pre-compact – makes sure no bits are in an over erased state.
2.
Clear – Programs all bits in the sector to 0.
3.
Erase – Sets all bits in the sector to 1 and
4.
Compaction - Corrects any “over-erased” (depleted) bits.
The Erase operation is a dynamic operation - pulses are applied until the erase is complete or the maximum number of pulses is reached and the erase fails. Thus the amount of time it takes to erase will vary per attempt and per sector. It will change at different temperatures, and in addition it will also change with ‘the number of previous erase/program cycles’ (flash endurance). Hence, it will also change from part to part. The system related issues/parameters (supply voltage, ripple/noise etc) will be on top of this. This will change with temp as well as during the lifetime of the flash.
In summary, the erase function of the different flash sectors is a highly dependable process. It depends on temperature, silicon age, number of previous erase steps, amount of flash used, etc. Therefore it is nearly impossible to predict a specific maximum timing for erasing flash sectors. If everything possible went to its absolute max, the MAX erase time would be extremely long. This can vary from chip to chip and is not characterized. Typically you will see a few seconds per sector to erase.
Always check the data manual for the latest write/erase time information for a specific device.
- Q: How does depletion occur?
A: If the erase operation is interrupted and not allowed to complete, the device may become depleted. When this happens, the device may then begin to fail to erase. The erase algorithm should not be stopped, as this can also affect the CSM passwords. The Flash API has a depletion recovery function to try to recover flash that has been "over-erased". If the flash programming process was interrupted during the erase stage, it is possible that the timed loops that do the erasing process were disturbed.
The CCS On Chip Flash Programmer does have support for the depletion recovery function. You will see it listed in the as one of the options that can be selected under "Operations" in the flash plug-in GUI. You can get additional information on this by clicking on the "Help" button, go to the search tab and enter "depletion".
The depletion recovery also looks for sectors that are in depletion and attempts to recover them. All sectors on the device are checked.
The current maximum timeout for the algorithm is approx 35 seconds per sector that is in depletion. Typically, only one sector would be in depletion unless erase has been called multiple times on multiple sectors without running to completion. If a longer timeout can be tolerated, the depletion recovery can be used multiple times.
There is no guarantee that this algorithm will be able to bring a sector out of depletion within a reasonable amount of time. The deeper in depletion the part is, the longer it will take to recover. The Flash API erase function has been implemented to erase the flash in such a manner that it is not put into deep depletion. However, if the CPU is halted during an erase pulse for a long period of time, the part can be put into a deep depletion that may not be recoverable in an acceptable time period.
This algorithm cannot recover the part if the flash passwords are unknown. For example, if power is lost during the erase of sector A, where the CSM passwords are located, then the device may be permanently locked and the recovery algorithm cannot operate on the flash.
If the depletion recovery step fails then replacement is the only option.
CSM (Code Security Module)- Q: What’s the most possible reason to cause CSM appears secure, and any solutions for these cases?
A: There are 5 different situations in which the CSM would either be secured or appear to be secure:
1.
Password Match Flow has not been completed
2.
The CSM has been knowingly programmed with a password
3.
The CSM has been unknowingly programmed with a password
4.
The CSM has been permanently secured by programming all zeroes into the password locations
5.
The flash is not powered as a result of the VDD3VFL power signal not being present
The solutions to above conditions are as follows:
1.
Run the password match flow by the method described in the CSM section of the System Control and Interrupts Reference Guide for the specific TMS320F28xxx device being used. This can easily be utilized from the device GEL file within CCS by selecting GEL -> Code Security Module -> Unlock_CSM().
2.
Unlock the CSM with the password that was programmed to it previously. The process to unlock the CSM with the CCS On Chip Flash Programmer is discussed in the Flash Programming Solutions for the TMS320F28xxx DSCs (SPRAAL3) Application Note.
3.
The previous .out file that was programmed to the flash could contain data that was written to the password locations. In this instance the Hex Conversion Utility supplied with CCS can be used to convert the .out file to a hex format and determine what data was written to the password locations. These values can then be used to unlock the CSM. If this .out file does not show data written to the password locations or the .out file is not available, the flash cannot be unlocked and the chip should be replaced.
4.
The CSM cannot be unlocked as all zeoes permanently secures the CSM. The CSM could have been permanently locked on purpose or could be the result of power failure or by stopping the erase procedure during previous programming cycle. This is discussed further in SPRAAL3.
5.
The VDD3VFL signal is either not present or is not supplying a clean power rail to the flash resulting in the flash not being powered. This will need to be corrected on the target board. This is discussed further in SPRAAL3. If the device is in a socket, make sure it is properly seated and making good connection.
In any of these cases, if the CSM is secure and the password is unknown, it cannot be unlocked to be reprogrammed.
- Q: The erasing operation is halted in the flash programming procedure, why it happens and any risk for CSM?
A: If the erase operation is interrupted and not allowed to complete, the flash may become depleted. When this happens, the device may then begin to fail to erase. The erase algorithm should not be stopped, as this can also affect the CSM passwords. If the passwords are in an unknown state, the device cannot be recovered. This can also leave all zeroes in the CSM resulting in a permanent lock. This is discussed further in the Flash Programming Solutions for the TMS320F28xxx DSCs (SPRAAL3) Application Note.
- Q: What are the scenarios that CSM gets locked automatically? Is it deterministic or not?
A: If a password is programmed into the flash, the CSM is locked on reset and stays this way until the password match flow is executed (refer to the System Control and Interrupts guide for your particular device).
If an application has unlocked the device, it can force a relock by writing a 1 to the FORCESEC bit in the CSMSCR register.
- Q: Why is all 0xFFFF's unsecure?
A: When the device leaves the factory the flash is in an erased state. In this state all locations, including the password, is all ones (i.e. 0xFFFF's).
- Q: How many passwords are there?
A: There is one 128-bit password. It occupies 8 contiguous words in flash.
- Q: How do you unlock the the CSM after all zeros have been written to the password locations?
A: When all zeroes are written to the password locations, this is a permanent lock and there is not a method to erase this password. This is documented in the CSM section of the System Control and Interrupts Reference Guide for the specific device being used. This section provides the following statement: Do not use 128 bits of all zeros as the password. This automatically secures the device, regardless of the contents of the KEY register. The device is not debuggable nor reprogrammable.
- Q: Is there anyway to erase the password?
A: If you know the password then you can unlock the flash and erase the password by erasing sector A.
- Q: Is there anyway to erase the password without erasing all of sector A?
A: No. The smallest amount of memory that can be erased is a sector.
- Q: Code that is running in unsecure memory can not read/write to memory that is secure or from Flash - why?
A: If the CSM is locked, then code running outside of the secure area will not be able to read or write to any secured location. The CSM must either be unlocked or the code must be relocated to one of the secure areas.
- Q: Will the CSM block the boot loader running in the boot ROM?
A: The boot ROM itself is unsecure and the boot ROM performs a dummy read of the CSM password locations.
·
If the device password is not programmed, then this will unlock the CSM and the boot loader will be able to write to secure memory.
·
If the device password is programmed, then the CSM will remain locked. In this case the boot loader will not be able to write to secure memory. One option is to provide your own loader in your application within secure memory (e.x. Flash). Using this loader you will be able to load to secure memory.
- Q: Code is running outside of the CSM protected area, and the CSM is locked. Can it branch to code within the CSM protected memory?
A: No, you can branch into the secured memory and begin execution without any additional setup. Note: this is different then trying to read values out of the flash through data or program space - this will be blocked. For example, code running in M0 SRAM (unsecure) can branch to code within the Flash even if the CSM is locked. Code running out of M0 SRAM will not be able to read any value out of Flash if the CSM is locked.
- Q: How can I tell which memories are protected by the CSM?
A: Refer to the Data Manual for the particular device. Memories that are protected by the CSM will be indicated in the memory map section. For example if L0 shows "Secure Zone" then it is protected by the CSM.
- Q: The CSM locks every time I reset the device Code Composer. Is this the intended behavior? Is there a work around?
A: Yes this is the intended behavior. It is easy to get around this during development. You can do one of two things.
1.
open a memory window in CCS to the CSM passwords. This will force CCS to read the passwords every time you halt or reset. If the password locations are erased (all 0xFFFF's) then this will unlock the CSM.
2.
In the gel file place the Unlock_CSM(); gel call in the OnReset() function to automatically unlock the CSM each time the processor is reset.. That is:
OnReset(int nErrorCode){
Unlock_CSM();} - Q: To unlock the CSM, does the dummy read come first or the load of the KEY registers first?
A: Either order will work. The ref guide says to do dummy reads of the PWL first, then write the passwords to the KEY locations. Some other examples may do it in the opposite order (i.e. loads the KEY registers and then does a dummy read of the PWL).
- Q: Is possible to program a device over the serial port with SDFlash if it is password protected?
A: Yes. The SDFlash algorithm will need to be built such that it knows the password of the device and can unlock it. This easy to do and is described in the readme file for the serial algorithm: http://emulators.spectrumdigital.com/utilities/sdflash/c2000/SDFlash_Serial_RefGuide_v3_3.pdf
- Q: Why does Code Composer Studio give me an emulator error when I try to connect to my locked device?
A: On devices with ECSL protection which do not support hardware wait-in-reset mode (such as the Piccolo devices), if the device is locked:
When the device is powered up, the CPU will start running and may execute an instruction that performs an access to an ECSL protected area. If this happens, the ECSL will trip and cause the emulator connection to be cut. To resolve this:
1.
Disconnect your emulator.
2.
Set your boot pins for "WAIT" boot mode. Note: on 2833x/2823x this is documented as the "loop to check" boot mode.
3.
Reset y**ice.
4.
Reconnect your emulator.
At this point you should be able to proceed and unlock y**ice.
GPIO- Q: Can I read the state of the pin (DAT register) even if the MUX is configured for peripheral usage?
A: 281x: No. On this device, the GPIODAT register reflects the state of the GPIODAT output latch.
On other devices: Yes. reading the GPIODAT register actually reflects the value on the pin.
- Q: Back-to-back DAT register writes do not work as expected
A: This is also described in the application note Programming TMS320x28xx Peripherals in C/C++ (SPRAA85).
Consider the following example. Running the code, the Green LED (A17) toggles as expected, but the red one (A16) stays permanently off. Setting a breakpoint and stepping through the code it works fine.
for(;;) {
/* Make LED Green */
GpioDataRegs.GPADAT.bit.GPIO16 = 1; //RED_LED_OFF;
GpioDataRegs.GPADAT.bit.GPIO17 = 0; //GREEN_LED_ON;
delay_loop();
/* Make LED Red */
GpioDataRegs.GPADAT.bit.GPIO16 = 0; //RED_LED_ON;
GpioDataRegs.GPADAT.bit.GPIO17 = 1; //GREEN_LED_OFF;
delay_loop(); }The above code will perform a read-modify-write of the DAT registers. The DAT register reflects the state of the pin itself (except on 281x devices). There is, however, some delay between a write to the DAT register and when the resulting value will be seen on the pin and then reflected back to the DAT. In this case the "GREEN_LED_ON" reads GPIO16 as low and writes that value back. Thus the RED LED never changes state.
One solution is to use CLEAR/SET registers for this example. Another is to place NOP's or other instructions between the read-modify-write instructions.
Note: on 281x the DAT register reflects the output latch and not the state of the pin. In this case the above code will work.
- Q: Toggling of the GPIO seems slower than it should be
A: Consider the following code.
//
// Toggle GPIO18//
GpioDataRegs.GPACLEAR.bit.GPIO18 = 1;
GpioDataRegs.GPASET.bit.GPIO18 = 1;
GpioDataRegs.GPACLEAR.bit.GPIO18 = 1;
GpioDataRegs.GPASET.bit.GPIO18 = 1;
GpioDataRegs.GPATOGGLE.bit.GPIO18 = 1; The attempt is to toggle GPIO18 as fast as possible. The bit method shown performs a read-modify-write. The read portion is wait-stated and since the peripheral frame has "write-followed-by-read pipeline protection" the next read won't occur until the previous write has completed.
Using .all to write to the whole register will remove the wait-stated reads and effect of the pipeline protection.
This is also described in the application note: Programming TMS320x28xx Peripherals in C/C++ (SPRAA85)
- Q: Toggling of the GPIO seems slower than it should be - Part 2
A: Consider the following code:
//// Toggle GPIO18// for(;;)
{
GpioDataRegs.GPADAT.bit.GPIO18 = 1;
GpioDataRegs.GPADAT.bit.GPIO18 = 0; } The above code has similar issues to that discussed before. This method uses a read-modify-write. Since the read portion is wait-stated and since the peripheral frame has "write-followed-by-read protection, the next read doesn't occur until the previous one completes.
Another issue is the for loop will introduce a branch which takes 4 cycles. So even if this code were changed to use the GPBTOGGLE register, you would see a overhead from the branch.
A: The fastest way is to perform back-to-back writes to the TOGGLE registers:
If this is done in a for() loop, then the loop will introduce a branch instruction which takes 4 cycles at the start of each loop. On floating-point devices you can do something similar with a repeat block instruction (RPTB) instead of a branch which will eliminate the branch overhead. In addition, back-to-back writes to this peripheral frame will introduce a wait-state. That is one toggle will take a cycle, but back to back toggles will add an additional cycle between the writes.
for(;;)
{
GpioDataRegs.GPBTOGGLE.all = 0x0002;
GpioDataRegs.GPBTOGGLE.all = 0x0002;
GpioDataRegs.GPBTOGGLE.all = 0x0002;
GpioDataRegs.GPBTOGGLE.all = 0x0002;
GpioDataRegs.GPBTOGGLE.all = 0x0002;
GpioDataRegs.GPBTOGGLE.all = 0x0002;
GpioDataRegs.GPBTOGGLE.all = 0x0002;
GpioDataRegs.GPBTOGGLE.all = 0x0002;
repeat...etc
} - Q: How long will this C instruction to toggle a GPIO pin take?
A: Consider the following code:
GpioDataRegs.GPBTOGGLE.all = 0x0002;You can take a look at the disassembly generated in the Code Composer Studio window. In general there will be
·
an instruction to set the data page pointer
·
an AND instruction to write to the GPBTOGGLE register.
On their own, each of these instructions take one SYSCLKOUT cycle.
If another write is made to the GPBTOGGLE register then the data page does not have to be set for the second write. Consecutive (back-to-back) writes, however, to GPIO registers experience a 1-cycle pipeline hit (1-cycle delay).
- Q: 2833x/2823x: The GPIOB MUX1 register is set correctly to 0x00000000 after reset, but when loading code it is set to 0XFFFFFFC0?
A: The GEL file TI supplies is probably setting up the GPIO for XINTF functionality on file load. This allows Code Composer to load debug code directly into the XINTF. Look in the 'on file preload' function and remove the enable XINTF call to stop this behavior.
- Q: What is the status of the GPIO after reset?
A: As with all C2000 devices, the muxed GPIO pins default to GPIO inputs (hi-impedance) at reset. This condition is not explicitly stated in text in the documentation, but is immediately obvious by looking at the default state of the GPxMUXy and GPxDIRy registers in the System Control User's Guide.
Note: For GPIO pins which are MUXed with the JTAG functions (for example, on F2802x devices), the TRSTn pin controls whether the pins default to GPIO or JTAG at reset.
Note: Even though all GPIO are set to be high impedance on reset, several have internal internal pull-ups which are also enabled at reset. See the Pull-up/Pull-down section below.
- Q: What is the value of the pull-up and pull-down resistors?
A: The internal pull-ups/downs are active circuits, not passive resistors. There is no Ohms rating. Rather, there are current ratings given in the data manual. You can roughly think of these ratings as the amount of current needed to overpower the pull-up/down and cause the pin to change logic level.
- Q: Can the pull-up and pull-down resistors be disabled via software?
A: On 281x: No.
On other devices: Yes for GPIO pins. Refer to the GPIO configuration registers in the System Control and Interrupts guide for your particular devices.
- Q: Are the pull-ups on pins that can be used as ePWM outputs enabled or disabled on reset?
A:
On 281x devices if a GPIO pin has a pull-up then it is enabled at reset and there is no way to disable them in software.
On all other devices:
If a GPIO pin can be used as ePWM, then the pull-up is disabled at reset. It can then be enabled by software.
If a GPIO pin can not be used as ePWM, then the pull-up is enabled on reset. It can then be disabled by software
The pin-list in the data manual will show which pins have pull-ups.
- Q: Is it possible to use the qualification function of the GPIO when the input is dedicated to a peripheral?
A: The qualification circuitry is active regardless of the setting of the GPIO mux. So, yes, you can use the qualification for the peripheral function.
- Q: I am looking for timing information for the qualification logic.
A: Please see the data manual for y**ice. This will be listed with the other GPIO timing parameters. |
|
楼主
标题置顶
标题高亮
