Thursday, March 29, 2012
'findViewById()' error in Android development
Saturday, March 24, 2012
Enabling SPI on BeagleBoard
[1] http://linuxdeveloper.blogspot.ca/2011/10/enabling-spi-on-beagleboard-xm.html
pin-mux:
Do not forget to patch
See [2] http://elinux.org/BeagleBoard/SPI for details. Here is the patch file:
[3] http://elinux.org/BeagleBoard/SPI/Patch-2.6.37
Actually, one can also customize U-boot to setup the pin-mux. Let's focus on the way provided by reference [2] now. After activating CONFIG_OMAP_MUX (You can do this by selecting 'System Type --> TI OMAP Implementations --> OMAP multiplexing support' in the kernel's make menuconfig. See [4] http://elinux.org/BeagleBoardPinMux for details.), I got a kernel panic error as mentioned in reference [2] and the following links:
[5] https://groups.google.com/forum/?fromgroups#!topic/beagleboard/Tmt1PS6KGmg
[6] https://groups.google.com/forum/?fromgroups#!topic/beagleboard/On9iVpUnWBI
(According to my tests, this panic error always occurs on the xM board. It may not happen on the original BeagleBoard as outlined by reference [6].)
To fix it up, reference [2], [5], and [6] gave a solution by commenting the line 'omap_cfg_reg(AH8_34XX_GPIO29);'. However, I cannot find this line in 'board-omap3beagle.c'. My kernel version is 2.6.34. Take a look at the git log, you'll find that new kernel versions do not support 'omap_cfg_reg()' anymore. I believe it was replaced by function 'omap_mux_init_gpio()', which appears in my 'board-omap3beagle.c'. Anyway, after commenting out lines:
'omap_mux_init_gpio(29, OMAP_PIN_INPUT);',
'omap_mux_init_gpio(23, OMAP_PIN_INPUT);',
and 'mmc[0].gpio_wp = 23;',
the panic error was gone.
The kernel image has been tested on both original BeagleBoard and xM board. 'spidev_test' results are good for /dev/spidev4.0, /dev/spidev3.0, and /dev/spidev3.1.
My next plan is to remap SPI3 on header P17 rather than the expansion header. I tried to modify 'board-omap3beagle.c' as follows:
static void __init omap3_beagle_config_mcspi3_mux(void)However, it does not work. I am still trying to figure out a solution.
{
// NOTE: Clock pins need to be in input mode
omap_mux_init_signal("etk_d3.mcspi3_clk",
OMAP_PIN_INPUT);
omap_mux_init_signal("etk_d2.mcspi3_cs0",
OMAP_PIN_OUTPUT);
omap_mux_init_signal("etk_d7.mcspi3_cs1",
OMAP_PIN_OUTPUT);
omap_mux_init_signal("etk_d0.mcspi3_simo",
OMAP_PIN_OUTPUT);
omap_mux_init_signal("etk_d1.mcspi3_somi",
OMAP_PIN_INPUT_PULLUP);
}
Monday, February 22, 2010
How to Debug STM32F10X ARM Cortex-M3 Microprocessor
1. Developing Tools
1) STM32F10x Evaluation Module
STM32F103 Evaluation Module was purchased from Olimex (www.olimex.com). This hardware toolkit is a test-bench to evaluate the features and performance of STM32 ARM Cortex-M3 microprocessors. In order to explore its on-chip peripheral devices, one may need an expansion board to provide connectors and interfaces.
Fig. 1: STM32F10X Evaluation Module
2) JTAG / Parallel Port Dongle
ARM-JTAG Dongle is a hardware toolkit to download user code into STM32 ARM. It helps to program the on-chip flash memory and debug the program as well. Note that all ARM microprocessors provide JTAG interfaces for the debugging. However, PC does not have such sort of ports, and, instead, prefers its parallel port to manage these tasks. Thus, ARM-JTAG Dongle works as an adapter between ARM and PC, exchanging data between JTAG and the parallel port.
Fig. 2: ARM-JTAG Dongle
3) Debugging Server Software
The host PC requires software to communicate with ARM-JTAG Dongle. A software tool named “H-JTAG” is selected as a server to control the programming, downloading, and debugging of ARM codes. It is a professional tool that can work with almost all ARM7, ARM9, ARM10, X-Scale, and Cortex processors. Although it is free, its downloading speed (up to 30kb/s) is even faster than commercial grade products. Also, it works well with many IDEs for ARM. See “H-JTAG” website (www.hjtag.com) and its user manual to setup this software.
There are lots of IDEs available for ARM. (i.e.: ADS from ARM, MDK from Keil, Embedded Workbench from IAR, WinARM from GNU community, etc.) The most popular ones are MDK and Embedded Workbench. Both of them work along well with H-JTAG. MDK offers more customizations as well as debugging features, and is thus selected as the IDE used in this project. The evaluation version of MDK is free, but within a limit of code size (less than 32KB). See Keil’s website for details (www.keil.com/arm/).
When do we need SRAM-based debugging?
During the stage of development, it is suggested to perform SRAM-based debugging. With no needs of erasing or programming flash memory, the debugger (H-JTAG) is able to download the code into on-chip SRAM directly. This could be way faster than flash operations, thus saving time for the debugging. Also, this method protects the flash memory, which can be erased or programmed for limited times.
How to setup SRAM-based debugging?
1) Install “H-JTAG” and “MDK” according to their user manuals.
2)
3)
Fig. 3: H-JTAG has detected the target microprocessor
4) Run “MDK” (Keil uVision3). Create a project by selecting STM32F103xb and its start code.
5) Select the “target” and right click to invoke the dialog of “option for target”.
6) Go to tab “Target” and setup ROM and RAM options as shown in Fig 4.
Fig.4: setup of on-chip ROM / RAM memory space
7) Go to tab “Linker” and select the option “Use Memory Layout from Target Dialog”.
Fig. 5: setup of the linker
8) Go to tab “Debug”. Select “H-JTAG CORTEX-M3” Hardware Debugger.
9) Create a file named “ram.ini”. It includes the following codes. Make it as the initialization file.
FUNC void Setup (void)
{
SP = _RDWORD(0x20000000); // Setup Stack Pointer
PC = _RDWORD(0x20000004); // Setup Program Counter
_WDWORD(0xE000ED08, 0x20000000); // Setup Vector Table Offset Register
}
LOAD nav_arm.axf INCREMENTAL // Download
Setup(); // Setup for Running
g, main
Fig. 6: setup of the debugger
10) Go to tab “Utilities”. Select “H-JTAG CORTEX-M3” as the driver for flash programming.
Fig. 7: setup of the utilities
11) Finish the writing of ARM program and compile it. Then, start the debug session.
3. Flash-based Programming
When do we need Flash-based Programming?
Once the code was verified and optimized, it can be downloaded to the flash memory of the microprocessor. In order to release the product, we need to perform Flash-based programming to store the firmware we’ve designed. As non-volatile memory device, flash is ideal to store the code no matter the power supply is available or not.
How to execute Flash-based Programming?
1. In MDK IDE, invoke the dialog of “option for target” and setup memory options as follows.Fig. 8: setup of on-chip memory space for the flash programming
3. Keep all the other options as the same settings of SRAM-based Debugging. Then, click OK.
4. Re-compile / Rebuild the whole project to generate the objective HEX file.
5. Start H-Flasher from H-JTAG. Setup H-Flasher and then program the on-chip flash memory.
(Configure H-Flasher according to the user manual of H-JTAG. Fill in the path of the HEX file that will be downloaded into the chip. See Fig. 10. for details.)
Fig. 9: setup of output files
Fig. 10: Using H-Flasher to program STM32F10x’s on-chip flash memory