Monday, August 11, 2008

a Book excerpt on Embedded Site

The following links a book excerpt is posted in embedded.com ebook.
DSP Tricks: A/D converter testing techniques and finding missing codes in ADCs

USB and Serial flash boot table for C55


USB bootloader bootable options in TI's 5000 series DSPs are hardware configured for choosing boot options, whether to boot from binary file downloaded through USB cable from host PC or from it's MCBSP serial port, etc.

Upon powerup, pre-programmed bootloader in the DSP chip starts to run and check hardware pins to decide from where it has to download the codes. Our program, which is output from the compiler ( .out file) can be converted into suitable format that's capable of system start up after being downloaded from respective interface, i.e. , USB or flash or external memory etc.

The following shows the option set up in .cmd file for hex55.exe

USB boot loader bootable options in .cmd file

Input.out .out file

-boot generate boot table

-v5510:2 boot table format = 2.0 for C5509a ( Modify accordingly)

-serial8 8 bits serial interface

-reg_config 0x1c00, 0x2810 CPU clock set to 192MHz ( maximum)

-delay 0x80 Delay program start to run after bootable finished downloading

-b output binary format

-o Output.bin name of output file

- map Output.bxp map file to describe detail of bootable memory allocation


EEPROM bootloader bootable options in cmd files

Input.out .out file

-boot generate boot table

-v5510:2 boot table format = 2.0 for C5509a

-serial8 8 bits serial interface

-reg_config 0x1c00, 0x2810 CPU clock set to 192MHz (maximum)

-reg_config 0x280B, 0x0004 MCBSP0 clock set to 1/5 of CPU clock = 38.4MHz (for faster download, this is optimized for 50MHz serial flash memory)

-b output binary format

-o Output.bin name of output file

- map Output.bxp map file to describe detail of bootable memory allocation


Friday, August 8, 2008

Some Useful Links for USB

Just wanna share some useful links with you today.
Though there are so many people explaining about USB, USB cables, USB protocol and how descriptors are exchanged and stuffs, I found the following links useful for those who wants to know what is going on in usb enumeration process.
Some might not find them necessary. But, of course, we firmware engineers deal with this low-level headaches ( headaches that we are addicted to .. haha! ) on everyday basis.
Next Monday, I will come up with Generating Boot table format for usb bootloading and serial flash bootloader for TI C55x processors. Now, Enjoy your weekend! Relax your Binary Reasoning and Analytical Intelligence Network and be more productive next week ^_^

USB Made Simple

How USB works


USB Interop Testing

Thursday, August 7, 2008

Checking Task Stack Overflow in DSP/BIOS

For embedded system, reliability is of great importance. At the later stage of development, with all functionality are tested working, we are left with this challenging work of optimizing speed and memory consumptions of each process thread in our system. Of course we all want to have freedom in assigning stack size to ensure that there is no overflow even when there are certain unfavorable events happen to our system. Yet, unfortunately, the nature of our work requires us to work in a box.
How can we check the task overflow?
In DSP/BIOS, we can make use of task-specific API to check Stack overflow for each task thread.
Firstly, How Task Specific Stacks are used for context switching and function Calling?

at Calling Function
1. Content of RETA to Stack Pointer’s TOS. Content of CFCT to System Stack Pointer’s TOS.
2. Return address (PC+1) to RETA. Loop Context to CFCT.

at Returning Function
1. Content RETA to PC. Content of CFCT to Loop Context bit.
2. TOS of Stack and SysStack to RETA and CFCT respectively.

Note:

TOS – Top of Stack
RETA – Return address register
CFCT – Control flow context Register
PC – Program Counter

Context Switch for DSP/BIOS threads

DSP/BIOS has 4 types of threads as arranged in the following in the order of highest priority to lowest.
1. HWI ( hardware Interrupt )
2. SWI ( software Interrupt )
3. TSK ( Task) and
4. IDL(System Task) – Inaccessible lowest priority system thread.

HWIs and SWIs use DSP/BIOS general Stack and SysStack as these threads will not be blocked until the processing is done. On the other hand, each task uses its dedicated task-specific Stack and SysStack. This is because tasks are blocking threads (can be suspended and preempted by higher priority threads) and it is needed to preserve context information for preemption context switch as well as its own function callings.

Allocation of Stack size and SysStack size for each task requires us to ensure that the stack doesn’t overflow while making the stack size (and thus the memory usage ) to be minimum.

DSP/BIOS Object Task_statistic can be used to determine the actual usage of stack, by reading the statistics at the end of thread before exiting. After observing the actual usage, the stack size can be adjusted. For detailed example, Refer to [ Ref: SPRU 432F DSP/BIOS User Guide, Chapter 4 Thread Scheduling ]

TSK_Stat statbuf; /* declare buffer */
TSK_stat(TSK_self(), &statbuf); /* call func to get status */
if (statbuf.used > (statbuf.attrs.stacksize * 9 / 10)) {
LOG_printf(&trace, "Over 90% of task's stack is in use.\n")
}

Wednesday, August 6, 2008

Hi

Hi There!
This is my first post, just to greet you all.
What is expected to come from this blog are embedded development tips, especially for TI DSP/BIOS. It has been my cup of tea for some years now and I feel like sharing some simple and helpful stuffs with you.
Have a nice day and see you again.
P.S. Don't forget to leave me comments or questions if you have any!