I wanted to add another update to this thread. I have been working on the software for this new board as I think that is the only problem I have been having.
As an aside: I spent this weekend following several guides found on the web that pertained to building the arm-none-eabi- toolchains. However, it seems that there is an issue with an assembly file, Trap.S, when building newlib-1.17 or later? It may have been a build issue or other problem. I don't know. I was able to build the arm-none-eabi toolchain using the standard gcc tools (specifically 4.6.4). However, the Freescale build SDK could not seem to find assert.h which is probably in the newlib which I couldn't get to build? I decided to move back to code sourcery. My experiment in building the tools started with the issues I posted on Friday where the prototype boards "seemed" to run (i.e.: current draw changed when loading binaries using the manufacturer tool but I never had console.
I decided to move to Code Sourcery (specifically 4.7.2 (Sourcery CodeBench Lite 2012.09-63). There is probably a newer version but this one is specifically called out in the Freescale 1.1 SDK. I then spent some of the weekend creating a project in the Freescale SDK which could be built and run on the custom board.
Step 1: Read all of the associated guides. The detailed level of reading is minimal as long as you follow the broad swaths
Step 2: In the "iMX6_Platform_SDK/board/mx6dq/", create a directory <my board> for use.
Step 3: Start with or directly implement an iomux output using the "iMX6_Platform_SDK/tools/windows/iomux/iomux.exe". (I am running a Windows 7 machine with an Ubuntu 12.04 VM)
Step 3.1: After porting in the nuance details of the hardware design, generate the associated code. The Design file for the iomux is going to be a *.xml. The iomux tool then generates an iomux_config.h and a rev_a_iomux folder with the intricacies to program the board through the SDK.
Step 4: I copied the DCD.c and the Makefile from the smart_device folder. I did this because I used the references from Freescale in the design of this board.
Step 5: Work through all of the compilation errors of ./tools/build_sdk -target mx6dq -board <my board>
Issues I corrected:
Step 5.1: [brute force] In hardware_modules.c, change the debug ports to the one that is on your board. For my custom board, I modified them to UART1 as I chose this as the debug interface. The board actually outputs UART1, UART2, and UART3.
Step 5.2: In sdk/drivers/board_id.h, Add to the section where board declarations occur
#elif defined (BOARD_<my board>)
#define BOARD_TYPE BOARD_TYPE_<my board>
This will help to register your board in the SDK
Step 5.3: In sdk/drivers/src/board_id.c, modify the function board_name switch statement to use your board and 'print' a name. This will show up in the terminal SDK output (Otherwise it will say unknown).
Step 5.4: In apps/obds/, I modified the Makefile to remove the src/tests/gpio_led.c and src/test/gps_test.c. This board has neither an LED to a GPIO nor a GPS module. This allowed me to bypass several errors (warnings really) that occurred in the build process.
Step 5.5: In /tools/build_sdk, add a field under valid_builds to be able to "register" your board in the structure. This is important as build_sdk won't know your board otherwise!
Step 5.6: Under the # Board area of config.mk (/mk/config.mk), follow the convention and add a -DBOARD_<myboard> with the else ifeq structure and then define the board as well.
Note: I may have made a couple other modifications but I am pretty certain that is it.
Step 6: Run ./tools/build_sdk -target mx6dq -board <my board> and let the whole area complete.
After getting through the SDK update, I ended up with output/mx6dq and a bunch of folders including the sdk_unit_test folder. In this folder, there is a subfolder with myboard and rev number. In that folder, there are several files including sdk_unit_test_ALL.bin. This binary file is the culmination of all of the SDK tests and is now build for my custom board.
Per the Manufacturing Tool v2 from Freescale, I then modified the way the manufacturing tool worked to allow for a new command set to program my board (at least initially).
I modified ucl2.xml by adding (this roughly can be found on page 8 of the README for the manufacturing tool):
<LIST name="DWLD_IN_SDP" desc="Download and execute a binary!">
<CMD state="BootStrap" type="find" body="Recovery" timeout="180"/>
<CMD state="BootStrap" type="boot" body="Recovery" file="sdk_unit_test_ALL.bin">Loading
<CMD state="BootStrap" type="jump">Jumping to SDK image.</CMD>
<CMD state="Updater" type="push" body="$ echo Update Complete!">Done</CMD>
I then modified the cfg.ini to use the name = DWLD_IN_SDP. Then I turned my board on, the board attached to my machine as the SDP loader. In windows it shows up as a HID compliant device. In linux (if you attach it to the VM), it shows up as the in the Freescale Semiconductor Recovery mode with the mx6DQ VID and PID using lsusb.
I then launched the MfgTool2.exe found in the Mfgtools-Rel-4.1.0_130816_MX6Q_UPDATED. I had to work through some issues getting the ucl2.xml and the cfg.ini to play nicely. Specifically, the README doesn't include the state= parameter on each line. I am assuming that v1 didn't need this but v2 definitely does! I then hit start and the code was loaded.
On my serial terminal I then received:
Platform SDK (1.1) for MX6DQ TO1.2 Aristeus rev. A<CR><LF>
Build: Jun 16 2014, 10:49:51<CR><LF>
Copyright (c) 2012-2013 Freescale Semiconductor, Inc. All rights reserved.<CR><LF>
========== Clock frequencies ===========<CR><LF>
CPU: 792000 kHz<CR><LF>
DDR: 528000 kHz<CR><LF>
IPG: 66000 kHz<CR><LF>
Debug UART: 80000000 Hz<CR><LF>
SDK Unit Tests<CR><LF>
<ESC>[01m<ESC>[35me<ESC>[00m - epit test<CR><LF>
<ESC>[01m<ESC>[35mg<ESC>[00m - gpt test<CR><LF>
<ESC>[01m<ESC>[35mi<ESC>[00m - i2c test<CR><LF>
<ESC>[01m<ESC>[35mw<ESC>[00m - pwm test<CR><LF>
<ESC>[01m<ESC>[35ms<ESC>[00m - sdma test<CR><LF>
<ESC>[01m<ESC>[35mr<ESC>[00m - snvs rtc test<CR><LF>
<ESC>[01m<ESC>[35mv<ESC>[00m - snvs srtc test<CR><LF>
<ESC>[01m<ESC>[35mt<ESC>[00m - tempmon test<CR><LF>
<ESC>[01m<ESC>[35mu<ESC>[00m - uart test<CR><LF>
<ESC>[01m<ESC>[35md<ESC>[00m - usdhc test<CR><LF>
<ESC>[01m<ESC>[35mc<ESC>[00m - gic test<CR><LF>
<ESC>[01m<ESC>[35mm<ESC>[00m - microseconds timer test<CR><LF>
<ESC>[01m<ESC>[35mwa<ESC>[00m - watchdog test<CR><LF>
<ESC>[01m<ESC>[35mo<ESC>[00m - ocotp test<CR><LF>
<ESC>[01m<ESC>[35mwp<ESC>[00m - cpu workpoint test<CR><LF>
<ESC>[01m<ESC>[35mh<ESC>[00m - hdmi test<CR><LF>
<ESC>[01m<ESC>[35mip<ESC>[00m - ipu test<CR><LF>
<ESC>[01m<ESC>[35mmc<ESC>[00m - multicore test<CR><LF>
<ESC>[01m<ESC>[35msa<ESC>[00m - sata test<CR><LF>
<ESC>[01m<ESC>[35mq<ESC>[00m - Exit menu.<CR><LF>
Select test to run:<CR><LF>
The control codes turn the characters to a color if in VT100 terminal emulation mode. I am using indigo terminal so the standard terminal just shows the control codes (which I prefer). I believe all of the clock frequency parameters are read from the chip through the hardware interfaces after the DCD programs them (if I have the control flow correctly). I also have DDR3 memory up and running. I can probe the memory and "see" activity; whether valid or not is a holistically different story. On my board, the COM Express as 12V goes from 250mA of draw to roughly 450mA of draw.
The next issue I have: It appears that I can't communicate through the UART1 serial interface after this point. The SDK is presumably waiting on input ("Select test to run:" is usually a prompt right?). The codes to run the tests are
I can send characters out. I can see the characters transmitting even with the Oscilloscope. But the I.MX6Q doesn't respond. I am wondering if somewhere have I not configured the SDK in all cases to ensure that the SD3_DATA6 and SD3_DATA7 ports remain in the control of UART1 (this is the configuration on my board)? Or is it running and just not responding because it hung up somewhere else.
Also: The Manufacturing tool doesn't seem to ever go to a completion state and the progress bar never turns from blue to green even though the system has "jumped". During one of the downloads, I added <CMD state="Updater" type="push" body="$ echo Update Complete!">Done</CMD> but have since commented it out as shown above. When I added it, the bar did turn green? But this could have been a fluke... unless this is how the MfgTool "knows" the that physical board has moved on?
The lack of serial communication post the splash message concerns me as probably a software issue? Has anyone out there seen or experienced this issue? Or does anyone have a greater insight into the SDK?