Changed of DDRv configuration. Note: when changed you need to restart DDRv Change cannot be seen in DDRv directly Look at JLink terminal window. Directory is somewhere like c:\Freescale\PExDrv v10.4\eclipse\Optimization\resources\Vybrid\DDR\templates\init\gdb_cwtap\ /Jiri

Valid ranges of tuning parameters for different setting of CR132, PHYs ... /Jiri

The QuadSPI bootloader found in the MQX installation folder needs an SD card that contains the images to load in iRAM or DDR. This means that the bootloader does not flash the application in QSPI memory, and using this bootloader in the field implies the need of an SD card every time the application needs to restart. NOTE: This document uses as reference MQX 4.1.1 The attached project is a modified bootloader_vybrid_qspixip project that works in the next way: The bootloader and applications are stored in QuadSPI memory. An application or bootloader upgrade can be performed, placing the new images in an SD card. The SD card is needed only to re-flash the QuadSPI memory. If and SD card is detected by the bootloader at startup and correct configurations and images are found, the bootloader will flash the images in QuadSPI. If it is not detected, the bootloader will execute the current image found in QuadSPI memory. The next figures show an example of the implementation. The BootROM code loads the MQX Bootloader from QuadSPI in iRAM.  When the MQX Bootloader starts, it checks if there is a mounted SD. If the SD contains valid application binary files and a valid configuration file it flash the images into the SD. BSP Changes To get this behavior a simple change in the QuadSPI driver from the BSP is required. In the file qspi_quadspi.c file of the BSP change line 898 to this: quadspi_reg_ptr->BUF3CR =     (quadspi_reg_ptr->BUF3CR & ~QuadSPI_BUF3CR_ADATSZ_MASK)  | QuadSPI_BUF3CR_ADATSZ(128);  /* AHB prefetch size: 128*8byte */ The attached file contains the  modified files that have to be used in the MQX bootloader_vybrid_qspixip project.

Freescale Vybrid offers key benefits for production GUIs, including low power consumption and layered architecture. This brief presentation offers details about how Altia's GUI development software leverages the unique features of the Vybrid to deliver first class embedded graphics.

The attached project shows a configuration for the DAC and its functionality is explained in the below points: The PDB triggers the next DAC conversion. The DAC features an internal buffer (DAC_DATx) that contains that data to be converted. The DAC data to be converted is determined by  an internal pointer. This internal pointer increases or moves to the next element in the buffer on every PDB trigger The DAC uses the Data Buffer as normal mode. This means that the buffer works as a circular buffer. When the internal pointer reaches some point in the internal buffer, the DMA is triggered and it transfers the new data from an iRAM buffer to the DAC internal buffer. In this specific example the DMA treats the source as a circular buffer, because the source buffer size is 512 bytes but the destination (DAC_DATx) buffer is 8 bytes. The below figure represents the configuration of the example: The frequency of each output sample is determined by the source frequency of the PDB and the DACINT value. Sample_Output_Frequency =  Source_Frequency/ [(PDB_MULT * PDB_PRESCALER) * (DACINT + 1)] In the attached example the Bus Clock = 66MHz., PDB_MULT = 1 ,  PDB_PRESCALER = 128, DACINT = 63 For the 256 elements to convert the frequency of the output signal is 31.47Hz. (Sine Wave)

This document explains the booting process of Vybrid using the QuadSPI module. The document is focused in how to generate a bootable image for the QuadSPI memory, explanation of the corresponding changes in the linker.

Unofficial User Manual for Rev.G Vybrid Tower board. (Skip page 1 if not loading properly - only title there.)

The VYBRID_SAMPLE_CODE from the website includes an DRAM init Script for the DS-5 Debugger. However it seems it doesn't correctly initialize the Vybrid Tower Samsung Memory. I modified some register settings and got this script works now for my Vybrid Tower Kit. Care must be taken when you again initialize clocks etc in your C Project because most of PLLs etc are already setup  in the script. Regards, Hans-Peter

Host Requirements and Setup BSP Download Target Requirements SD Card boot-up

Here is a quick summary at booting u-boot on the  TWR-VF65GS10 Vybrid tower board. This is an adaptation of u-boot on the i.MX6 sabre sd platform in a few commands for Vybrid, now that mainline u-boot has proper support. This assumes you already have a "working" Linux development environment with some ARM cross-compilers at hand (e.g. Debian + Emdebian). Get u-boot sources We will use git to fetch the U-Boot sources:   $ git clone git://git.denx.de/u-boot.git This should create a u-boot directory with all the latest sources. Note that for more stability you might want to checkout a release instead of the latest version; to do so, list the available release tags with e.g. git tag -l 'v2*', and git checkout <the-desired-tag>. Vybrid support in "mainline" u-boot is fairly recent so you will need a tag no older than v2013.07. Compile Assuming your cross compiler is called e.g. arm-linux-gnueabihf-gcc, you can compile by doing:   $ cd u-boot   $ export CROSS_COMPILE=arm-linux-gnueabihf-   $ make vf610twr_config   $ make This should create a number of files, including u-boot.imx. Put on SD U-boot should reside at offset 1024B of your SD card. To put it there, do:   $ dd if=u-boot.imx of=/dev/<your-sd-card> bs=1k seek=1   $ sync Your SD card device is typically something in /dev/sd<X> or /dev/mmcblk<X>. Note that you need write permissions on the SD card for the command to succeed, so you might need to su - as root, or use sudo, or do a chmod a+w as root on the SD card device node to grant permissions to users. Boot! Your SD card is ready for booting. Insert it in the SD card slot of your Vybrid tower board, connect to the USB to UART port with a serial terminal set to 115200 baud, no parity, 8bit data, power up the platform and you should see something like: U-Boot 2013.04-00300-g3d9138e (Jul 09 2013 - 11:57:02) CPU:   Freescale Vybrid VF610 at 396 MHz Reset cause: WDOG Board: vf610twr DRAM:  128 MiB WARNING: Caches not enabled MMC:   FSL_SDHC: 0 In:    serial Out:   serial Err:   serial Net:   Phy not found PHY reset timed out FEC Warning: failed to set MAC address Hit any key to stop autoboot:  0 => Enjoy! See also... u-boot most common mission is to boot the Linux kernel. See this post for details on how to do it (on i.MX6). If you plan to compile u-boot often, you might want to use a C compiler cache; see this post. Running a Script in U-boot u-boot on the i.MX6 sabre sd platform in a few commands

This document will cover some of the most commonly asked questions we've gotten about Vybrid. Anything requiring more in-depth discussion/explanation will be put in a separate thread. All new questions should go into their own thread as well. Vybrid Logistics: Where can I find a datasheet, reference manual,and more? The Freescale Vybrid website Where can I find schematics, layouts, and more on the Vybrid tower board TWR-VF65GS10? The Freescale TWR-VF65GS10 tower board website Software: Which core does MQX run on? MQX can run on the A5, on the M4, or on both cores at the same time. It's very flexible! Can Linux run on the M4 core? No, it requires an MMU which only the A5 has. Where can I find MQX? At http://freescale.com/mqx 4.0.1 has support for Tower board 4.0.2 will add support for Auto EVB (not yet released and available only to specific auto customers) I can't get USB1 to work with MQX See this thread "USB1 not working in MQX 4.0.1 (Tower) and 4.0.2 (Auto)?" Where can I find Linux? For F-series parts, the Linux BSP and support is provided by Timesys. You can register for access here: https://linuxlink.timesys.com/register/freescale/ Vybrid Dual-Core: How do I start the M4/secondary core? Two steps: 1) SRC->GPR[2] = <start address> + 1; //since M4 is thumb 2) CCM->CCOWR = 0x15a5a; //Start secondary core Now the M4 core (or secondary core) will start executing, while the primary core moves on to next instruction. Is there a limitation on when I can turn on the M4 core? No, you can literally turn it on as one of the first instructions that the A5 executes. Just be aware in code about which core would set up shared modules like clocks. I have a Vybrid tower board which has a dual core part. How do I only use the A5 core? Simply don't turn on the M4 clock. You have to explicitly enable the M4 core to start it. What can I do on a tower board which has a A5 primary part, but I'm interested in evaluating an M4 primary part? See this thread Are there limitations on which core can access which modules? Generally both cores can access any of the peripherals modules and memory. The exceptions are that only the A5 has access to the MMU and L2 cache. Only the M4 has access to the Tightly Coupled Memory (TCM). Also only the A5 has TrustZone, meaning that for a completely secure boot, you must have an A5 primary part. Is there hardware coherency checking? No, all coherency must be done in user software.This is an important consideration when caching a shared memory space between the cores. Can I reset just one core? Because so much of the Vybrid platform is shared between the two cores, there is not a mechanism to just reset one of the cores. See this thread for more information: Reset A5 without interfering on M4 What is this Multi-Core Communication (MCC) I hear about? It's an API developed between Freescale and Timesys to provide easy communication between the A5 and M4 cores. You can use it to transfer data between Linux on A5 and MQX on M4, or between MQX on both cores. You are not required to use it, as it is just a software option, but it will probably make your coding easier. Documentation on it can be found on the Timesys website and in the MQX release in the "docs" folder Is MCC the same as MQX's Multi-Processor Communication (MPC)? No, MPC has been in MQX for years, and is used for two physically separate MCUs to communicate/share data over a UART or Ethernet connection. This would cause unnecessary overhead on Vybrid, as which both cores are on the same die and share memory, so hence MCC was created. Vybrid General: How do I know if I have a 1.1 part? It will be marked with 1N02G. A 1.0 part will be marked 0N02G. Software can also look at address 0x80. It will be "11" on 1.1 parts. It'll be "10" on 1.0 parts. Rev G boards onwards have 1.1 parts. What changed between 1.0 and 1.1? Will I need to rewrite my code or redesign my board? Very few fixes would affect code or board design, so 99% of people would be OK. You can successfully run Linux and MQX on both 1.0 and 1.1 parts with *no* changes in the software or hardware. The only issue we've seen on some custom boards is when DDR settings weren't optimized, and thus some failures occurred due to normal process shift when new silicon arrived. Once the settings are tweaked to be centered and optimal, then the same code worked on 1.0 and 1.1 parts. This was not required for all boards. I sampled a part that has no L2 cache, and the code that worked fine on the tower board no longer works on the non-L2 part. What's going on? The Vybrid tower board has a part which has L2 cache. Most software was developed for that board, and thus assumes the part has L2 cache and tries to enable it. If your part does not have L2 cache and an attempt is made to configure the L2 cache, then it will crash your system. Remove that code. What is this trade-off between L2 cache and internal SRAM? All chips have 512KB of "System" SRAM with ECC protection. On chips without an L2 cache, there is an additional 1MB of graphics RAM for a total of 1.5MB of internal RAM. On chips with an L2 cache, there is an additional 512KB of graphics RAM for a total of 1.0MB of internal RAM. The chip on the TWR-VF65GS10 has an L2 cache, and thus has a total of 1.0MB of internal RAM Can the graphics RAM be used for things besides the DCU graphics buffer? Yes, it can be used and divided up for any purpose, including extra RAM for software. The name is only used to designate that it does not have ECC protection, and that it has the pixel convertor feature available. Do I have to use a NPN transistor to supply the 1.2V core voltage? Can I just power it directly? See the following thread for a detailed discussion on the pros/cons of doing that: Re: Power supply for Vybrid core I'm trying to use the DCU and nothing is coming out! Make sure the TCON module is in bypass mode I'm trying to boot an M4 primary part and it's not working. Why? The boot header information and location that header is at would be the same irregardless of the primary core. The exception is the start address. If using an M4 primary part, remember you must add +1 to the address since the M4 is thumb only. Vybrid Tower Board: I just got a Rev G board, and everything seems broken compared to my old board. Why? See this thread Why don't I see any output on the TWR-SER? You need to either adjust the terminal port used, or adjust the jumpers to direct the default terminal port to the TWR-SER. See this thread Why can't I debug with the OpenSDA port? By default the virtual-serial app is used as the OpenSDA app. You'll need to load the CMSIS-DAP app in order to start debugging. See this thread When using CMSIS-DAP with DS-5, sometimes my program download fails, particularly if it's a large amount of data. How can I fix this? Use the Updated CMSIS-DAP application My board has stickers that say "SCH-27442 REV G" (or G1) and "700-27442 REV H" (or Rev J). What board revision do I have? That is a Rev G or Rev G1 board. At the time of this writing (October 2013) Rev G1 is the latest version. What is this OpenSDA I keep hearing about? See this thread How do I choose between different boot devices on the Tower board? Jumper J22 is used to select the boot mode and device. See Page 10 of the TWR-VF65GS10 Quick Start Guide for details and jumper settings. My board is acting weird. It sometimes works and sometimes doesn't, or crashes after a while. What's going on? Make sure you have both ends of the dual USB cable that came with your board connected. Depending on what programs you're running, like Linux playing an mpeg file on the TWR-LCD-RGB, a single USB port may not be able to supply all the necessary power. I'm powering via the elevator board, and sometimes things are flaky. What's going on? There is a potential voltage drop in high-current situations with the current elevator boards. This is being fixed, and more robust elevator boards will be available in July. In the meantime, we do not recommend powering via the elevator. Use J3 on the Vybrid MPU board instead. Also see this comment. What other things can cause issues? Make sure you're not booting off the SD Card or QuadSPI when trying to debug other code. Since that code might have already been running, then it can interfere, for example in clock setup, with the code you're trying to load into DDR/SRAM and debug. Also if trying to boot off the QuadSPI and nothing is programmed into it, then odd things may happen. The best thing to try is to remove the jumpers on J22, pins 1-2 and 3-4, which puts the board into serial boot loader mode and prevents other code from running. How do I program the QuadSPI? IAR 6.50.3 or later supports built-in programming on one of the QuadSPIs. This is being added to DS-5. You can also use the QuadSPI Loader project in the bare-metal sample code to program the QuadSPI. Instructions are in \src\projects\quadspi_load\readme.docx Tools: I'm having connection and debug issues with 5.14, why? There are some bugs in DS-5 5.14. Please upgrade to 5.15.1 What is the difference between the versions of ARM DS-5? There are two Vybrid specific versions of ARM DS-5 available: The DS-5 Vybrid Tower Starter Kit is a node-locked 1-year 256KB code size limited license that is complimentary with each Vybrid Tower board purchase. It will only work with the Vybrid tower board. The DS-5 Vybrid Edition is a node-locked 1-year 1MB code size limited license that has several advanced features. It is available if you buy a TWR-VF65GS10-DS5 tower kit. It will work with any custom Vybrid board. The two versions above will work for Vybrid only. Further details can be found on the ARM DS5 Vybrid page. The normal full version of ARM DS-5 will give you access to Vybrid plus other Freescale and ARM devices. Can I debug both cores at once? How do I do that? Yes. In DS-5 you can connect to the board either via CMSIS-DAP with only a USB cable, or by using a DStream, and debug both cores at once in the same debugger. The instructions for using DS-5 that come with MQX go through an example of doing this with the pingpong MCC example, can can be found in the doc\tools\ds5 directory. You can also read the DS-5 QSG You can also debug both cores in IAR by opening two instances of IAR with a JLink debugger. Instructions can be found in MQX in the \doc\tools\iar folder What should I watch out for when debugging both cores? When entering debug mode on either core, it enables a system-wide internal debug signal which will halt timers and watchdogs. So for instance, if the M4 core is using the PIT, and only the A5 core is halted, the PIT will still stop counting (unless PIT_MCR[FRZ]=0). Or if using the LPTimer, all the clock sources for it will be stopped when either core is stopped. I get errors when I open the bare-metal code example projects. Why? They are built with the latest releases as there are several new Vybrid features. Please ensure you are using at least: IAR 6.50.6 DS-5 5.15.1