Attention to all developers:
QueryPerformanceCounter() on efusA9 on WEC2013 F&S Version 1.40 seems to return a per-core counter, resulting in start time larger than stop time when a thread which measures short amounts of time runs on one core to get the start time and then on the other core to get the stop time.
Hello,
I downloaded the SDK (ndcucfg_lib.h and ndcucfg_lib.lib). I get this error at link time:
1>------ Build started: Project: mcu-fw-x, Configuration: Release FSiMX6 WEC2013 ------
1>LINK : fatal error LNK1113: invalid machine type 0x1C2
========== Build: 0 succeeded, 1 failed, 1 up-to-date, 0 skipped ==========
Seems as if the LIB is not intended to be used with FSiMX6 WEC2013.
I got a new SDK and then could implement using the I²C. Now I use the I2C2: device on the efusA9 (I2C_B).
By the way: The Document WINCE_FSiMX6_DeviceDriver_eng.pdf contradicts with the actual registry settings for the Touch drivers.
The Touch drivers have "I2C3:" set for the I2CDevice registry value.
The PDF document states, that the Touch drivers use "I2C2:" and one should use "I2C3:" for other purposes.
By the way, if anyone needs it: Here are my settings for the NEC NL10276BC13 TFT Display (6,5", 1024x768, LVDS):
reg open \drivers\display\lcd
reg set value Mode dword 100
reg set value OutputDevice dword 16384
reg create key Mode100
reg open \drivers\display\lcd\Mode100
reg del value Prefix
reg del value ExtDll
reg del value PWMDevice
reg del value PWMChannel
reg del value Freq
reg del value DutyCycle
reg enum
reg set value Name string "NEC NL10276BC13"
reg set value Type dword 0x00004006
reg set value Config dword 0x12300000
reg set value Columns dword 1024
reg set value PPL dword 1024
reg set value BLW dword 159
reg set value HSW dword 1
reg set value ELW dword 160
reg set value Rows dword 768
reg set value LPP dword 768
reg set value BFW dword 18
reg set value VSW dword 1
reg set value EFW dword 19
reg set value Width dword 132
reg set value Height dword 99
reg set value Bpp dword 16
reg set value ContrastEnable dword 1
reg set value ContrastValue dword 0
reg set value ContrastFreq dword 20000
reg set value LCDClk dword 65
reg set value EnableCursor dword 1
reg set value Rotate dword 0
reg set value Msignal dword 2
reg set value HVSync dword 2
reg set value PONLcdPow dword 0
reg set value PONLcdEna dword 0
reg set value PONLcdBufEna dword 0
reg set value PONVeeOn dword 0
reg set value PONCflPow dword 0
display mode set 100
reg save
reg open \drivers\display\lcd
reg enum
reg open \drivers\display\lcd\Mode100
reg enum
OK, i found out how to use BL_CTRL:
The PWM value of BL_CTRL is the "contrast voltage". So I added these lines to my Display Config script for NDCUCFG:
reg set value ContrastEnable dword 1
reg set value ContrastValue dword 0
reg set value ContrastFreq dword 20000
The Frequency on my oscilloscope actually is 50 kHz.
contrast set 0 -> 99,x % duty cycle (full brightness)
contrast set 4095 -> 0 % duty cycle (completly dark)
Hello,
are the BL_CTRL and VCFL_ON signals of the efusA9 already implemented in WEC2013 F&S Kernel 1.40? Are the signals usable even if the display is connected to the LVDS connector?
I would like to switch the display on and off and to dimm the backlight darker and brighter from our application.
I already checked the Changelog and Roadmap but did not find anything about them. I already checked the device driver documents but I did not find information dedicated to the efusA9.
I have investigated further and want to share my results with other efusA9 or i.MX6 users as well as the developers at F&S.
Environment:
Results:
The Network performance is only a problem at 1 GBit/s. At 100 MBit/s everything is fine. I did not try whether I could force the link speed to 100 MBit/s with a registry setting. I just used a 100 MBit/s Switch. One cannot simply set the mode to 100 Mbit/s Full Duplex, because that would result in an duplex mismatch when connected to an auto-negotiating link partner, further resulting in packet loss. The only option to force the efusA9 to 100 MBit/s would be to set it to 100 MBit/s HALF DUPLEX, which is not desirable, as collisions might occur.
At Gigabit the performance heavily depends on the IEEE 802.3x flow control mechanism. I was only able to reach about 200 kByte/s FTP Transfer speed on Gigabit connections, regardless whether using a direct connection or a Gigabit switch.
PLEASE NOTE: There is obviously an translation error in the german Intel PRO/1000 network driver dialog which allows setting the Flow Control Mode.
German version: "Tx aktiviert: Der Adapter hält die Übertragung an, wenn er einen Flusssteuerungs-Frame von einem Verbindungspartner empfängt."
English version: "Tx Enabled : The adapter generates a flow control frame when its receive queue reaches a predefined limit."
The two descriptions contradict. I used this setting and accidently turned off the reacting on the Flow Control PAUSE Frames.
Therefore using the "Tx Enabled" mode in an direct connection to the efusA9 results in overrunning the i.MX6 Ethernet device with too many frames per time unit. That happens when sending an UDP packet with a size larger than an Ethernet frame (e.g. 18088 bytes) which is fragmented into multiple IP packets packets/frames. The efusA9 seems to lose at least one fragment and is unable to reassamble the whole packet. The interesting point is the following: In this situation (overrunning the efusA9 without reacting on the Flow Control PAUSE Frames) the TCP Performance is much better at about 6500 kByte/s.
Conclusio:
The best solution for my needs at the moment (WEC2013 application development) is the use of a 100 MBit/s switch. It ensures not packet loss in UDP (application protocol) and fast TCP communication (needed for deployment and debugging). When the product gets shipped, it will be connected to Gigabit switches and operated via UDP and normally no TCP communication will occur then (which would be very slow...). So I am lucky and can live with the drawbacks for now. But what if i would have to implement some TCP application in future? Or someone else has an TCP application, operating on a Gigabit Switch? There should be made improvement to the 200 kByte/s limit.
Hello,
I have the following problem: After not powering the efusA9 for a few days and then powering it up, it does not boot into WEC2013, instead it puts <0> (zeros) out at the serial port at approx. 1 Hz rate. RESET does not change anything. Only power off and power on again makes the device boot.
What could cause that?
I encountered the problem on the Startinterface as well as on our own carrier board.
Martin
Symptom: The application deployment to debug directly from Visual Studio 2013 takes 100 seconds to transfer 6 MB into the WEC2013 memory file system over a Gigabit Ethernet link.
I investigated the TCP traffic from my development machine to the efusA9 (with WEC2013 from 2015-10-17, operating on the Startinterface board) and encountered many retransmissions caused obviously by TCP segments that were lost on the efusA9 (the segments are definitly seen on the network). The retransmissions cause the sender to perform pauses of 200-300 ms (may be part of the congestion avoidance algorithm) before transmitting the "lost" segment. That behavoiur prolongs the transmission of 6 lousy megabytes to 100 seconds.
I do not blame it on the sender. It performs correctly, but I think that the receive window size of the WEC2013 TCP stack does not correspond well to the maximum number of frames the network driver can hold before the stacks processes them. In other words: The announced receive window is larger than the amount data the network driver can hold.
Please check for this particular behaviour. It also occurs with other TCP traffic like the FTP transfer. I can provide Wireshark network dumps, if that helps.
Hi,
I just discovered that disconnecting the efusA9 Ethernet Interface from a Gigabit-Switch and connecting it again to a Fast Ethernet Switch results in "no communication possible" (no ping, no other network connection). After reconnecting to the Gigabit-Switch the device is reachable again.
It turned out that the efusA9 with WEC2013 is stuck to the link speed negotiated during the first boot. Because if boot with Fast Ethernet Switch connected, the device is pingable, but not after reconnecting to the Gigabit Switch without reboot.
Maybe the link change is not handled properly by the driver?
Hello,
when will SPI be available for efusA9 under Windows Embedded Compact 2013 (WEC2013)? I am using XIPiMX6SDL_C8GE_141017.bin (latest version visible to and downloadable by me in "Mein F&S")
By the way: Where can a i find the necessary SDK for programming the I2C and SPI interfaces? I installed the latest FSIMX6_WEC2013_SDK_VS2013_141016.msi, but did not find andy I2C header files in there.
I had the same problem ("Unknown file type can NOT write in Nandflash").
I found your post and did like you but again, i received the "Unknown file type" error. After putting the nbootIMX6SDL_17.bin file into the folder Profiles\MX6DL Bootloader\OS Firmware\ and modifying the ucl2.xml to use the file AND using 'D' instead of 'd' i was able to transfer the nbootIMX6SDL_17.bin.
In the meanwhile i was able to get it working. I installed a newer EBOOT (ebootIMX6SDL_09.nb0) and the XIPiMX6SDL_C8GE_141017.bin. I did a "reset to factory default configuration" in EBOOT and retransferred the file via NDCUCfg.
(I tried out the mentioned "XDE" command in NBOOT, EBOOT and NDCUCfg, but neither of these tools recognized the command.)
Hello,
I am using an efusA9 DL with WEC2013 on the Startinterface Kit in combination with a NEC NL10276BC13 display.
I have inserted a user defined display mode (Mode100) into the registry and set the display mode to 100. After rebooting the registry setting for Mode has the value 18 instead of 100. The registry has been proberly saved (the Mode100 key is present and all settings are valid).
What or who sets the Mode to 18 during boot? If it is EBOOT, how can I configure it not to do so?
Regards
Martin Mödlinger
