AN01027 i2c issue Topic is solved

If you have a simple question and just want an answer.
User avatar
mon2
XCore Legend
Posts: 1812
Joined: Thu Jun 10, 2010 11:43 am

Re: AN01027 i2c issue

Postby mon2 » Mon May 25, 2020 3:43 pm

Hi.

1) To confirm, if you flash your "Hello World" IP into your custom PCBA, your product will boot and work correctly upon each fresh reset / power up cycle? If yes, this validates that the internal flash is being programmed correctly using the QSPI interface + the external 1K resistor on X0D01 is forcing the use of the internal flash for booting.

This is good news.


2) Be 100% sure that your USB cable is fully loaded = 4 wires and NOT just a charging cable - yup they do exist and are only 2 wires = Vbus & Ground to save on production costs.

Best if you use a short as possible, branded USB cable from CUI, Tripplite, Belkin, Molex, etc.

Regardless, do test with other cables you may have around your lab. If your cable is USB A/B connectors that most likely they are "fully loaded" and capable of data transfer as well.


3) Noting the above, suspecting the issue is related to the VBUS detect and that you are SELF powered vs. Bus Powered (ie. from the USB port on your host PC).

Really doubting at this stage that you are consuming high currents. Can you remove your external power supply and disconnect the +5v feed from your external power supply?

Then mate the +5 input to your power rails to connect to the Vbus of your USB connector.

Then test again. This should synchronize the power up and USB enumeration process since you are then Vbus (BUS) powered.

It has been a while but I recall a #DEFINE in the code for SELF POWERED - not sure if that will make a difference.

The fact that your "Hello World" code is working states a lot of positive news for your design.

Post back when you can with the results.
View Solution
__BriKs__
Active Member
Posts: 39
Joined: Tue Nov 27, 2018 9:45 pm

Postby __BriKs__ » Mon May 25, 2020 9:10 pm

mon2 wrote:
Sun May 24, 2020 11:28 pm

1) launch your toolchain -> create a fresh workspace (ie. 05242020 sounds good).

2) IDE -> see the EXAMPLES ICON on the LEFT pane -> select it -> then type HID on the search bar and you should see the AN00129.

Double click to import into your workspace. Select FINISH. Project -> Build ALL. You will see some errors but they will auto-resolve all except one. The LIB_XASSERT will not - do not know why other than to cause irritation. Why not just have perfection? In another life perhaps...

See the attached screens on how to compile and resolve the raised quirk.

mon2, I try rebuilding HID exemple following exactly your sequence. Build but not for the right target, my board is based upon XUF208 256 TQ64 C10 which is single tile device, then when I try to run get the architecture mismatch, seems normal. But Iv'e a question, how to change on this project the target ? I ask because to run the hid custom I always start from a fresh project with XUF208 XN files and add manually files endpoint0.xc, hid.h and main.xc and changing the target is interesting for me.

Again, thanks you for support!

Screen with achitecture mismatch
You do not have the required permissions to view the files attached to this post.
User avatar
mon2
XCore Legend
Posts: 1812
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Mon May 25, 2020 10:08 pm

Try the following...

On your project tree -> right mouse-click the Makefile and open to edit (see attached screens)

Change the target to exactly as shown in the attached screen - this reserved label will then be used by the compiler to target your CPU.

Save the new makefile -> CLEAN -> BUILD ALL and test again to check on the results.

In your makefile, you can delete the few top lines so that they read as follows for your target CPU:

Code: Select all

# The TARGET variable determines what target system the application is 
# compiled for. It either refers to an XN file in the source directories
# or a valid argument for the --target option when compiling.

# In this case, the target depends on the build configuration.
TARGET = XUF208-256-TQ64-C10  
If you wish to change to other XMOS CPUs, you can review the TARGETS folder inside the install folder for your xTIMEComposer toolchain to locate the respective proper keyword.

OR

You can start a fresh project -> select the SHOW DEVICES in target selection flag -> scroll to find your CPU (or just select the proper kit if you have a kit) -> the toolchain will then build the makefile for you. Then you can review what the makefile did allocate for the target CPU and use the same value for your project. A work around ...
You do not have the required permissions to view the files attached to this post.
__BriKs__
Active Member
Posts: 39
Joined: Tue Nov 27, 2018 9:45 pm

Postby __BriKs__ » Mon May 25, 2020 11:43 pm

Hmm, I build using correct target CPU in make file, now can launch debug or run but still nothing append when plug USB to my win 10 PC.
I try to flash instead of run (icon with lightning near the run icon on Xtime). This flash my cpu and after there is USB notification on my win 10 pc!
As unknow USB device with fail to ask device descriptor, the yellow warning icon but I feel i'm not far :)

Didn't undertsand why this happends only with flashing the cpu and not when run command on xtime ?

Off course I try with my audio application and same behavior (only yellow warning appear when using launch instead of run).

Attached the win10 device manager with audio app but hid app same behavior (in french sorry).
You do not have the required permissions to view the files attached to this post.
User avatar
mon2
XCore Legend
Posts: 1812
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Mon May 25, 2020 11:59 pm

Is the code compiled for self powered?

Try to power your hardware all off the USB vbus +5v0 rail and test again.

Concerned about the detection of the USB connection with the IP.

There is also freeware USB monitor software that can help here but the mouse IP should work as-is.

What are the posted error codes by windows for the yellow marked devices?
__BriKs__
Active Member
Posts: 39
Joined: Tue Nov 27, 2018 9:45 pm

Postby __BriKs__ » Tue May 26, 2020 8:47 am

I work again on hid mouse example.

-code compiled for self powered : I don't know :/ Try to serch a string with self powered but didn't found anything inside project files (nothing in makefile nor other .xc files)
-I try to plug/unplug usb cable in order to force vbus off/on when xmos is powered and each times an unknow usb device is detected. It is difficult to make my design self powered because of all dc/dc regulators are inside large power/gnd plane.
-errors codes:

\DEVICE_DESCRIPTOR_FAILURE
Pilotes surclassés : usb.inf:USB\DEVICE_DESCRIPTOR_FAILURE:00FF2000
Appareil mis à jour : false
Appareil parent : USB\ROOT_HUB30\4&359f8c85&0&0

I have two issues now: why usb try to run only when the XMOS is flashed and why this don't work :)
I post my project.

UPDATE: My project setting regarding self powered is ON:
in main :
on tile[0]: xud(c_ep_out, XUD_EP_COUNT_OUT, c_ep_in, XUD_EP_COUNT_IN,
null, XUD_SPEED_HS, XUD_PWR_SELF);
And now when I use RUN command on Xtime my pc show a usb notification as usb unknow device (device description failled), just like when I flash the cpu.
ALso try XUD_SPEED_FS instead of HS, build but same behavior usb device unknow.

Then my issues are resumed to only one: make usb working :)

Then I check with multimeter the right continuity between an usb cable and pins of the xmos, all seems good, see attached files which explain what I made.

At this stade I doubt about my Xmos CPU or hw implementation, XUF208 usb part fried ? A mistake in my schematic/layout ? I more than triple check layout and shematic but didn't see anything wrong.

UPDATE: I add -g option to makefile to debug and see if hid stay locked somewhere. I see the 3 process start but one of them stay inside a loop waiting for usb clock, maybe the issue is here?
Attached the debug mode showing one process staying in a loop.
You do not have the required permissions to view the files attached to this post.
User avatar
mon2
XCore Legend
Posts: 1812
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Wed May 27, 2020 7:06 pm

Hi.

Download and run this free tool -> then index the USB function that is related to your custom PCBA to validate if the descriptors are valid or not:

https://www.thesycon.de/eng/usb_descriptordumper.shtml

BTW - The XMOS USB Audio firmware IP was reported to be not 100% valid for the descriptors using this tool but can be fixed by modifying the data structure manually and then testing again with this tool. Through this repeated process, we recall fixing the descriptors last year inside the XMOS source code. Best if you do the same when you are onto this project for the best field compatibility.

Based on your debug locked state, perhaps the 24Mhz signal is not reaching the CPU CLK pin?

Curious to see the output from the above tool.
__BriKs__
Active Member
Posts: 39
Joined: Tue Nov 27, 2018 9:45 pm

Postby __BriKs__ » Wed May 27, 2020 8:46 pm

Hello mon2, hope you are doing well :)

I test to switch oscillator form a hw point of view. Then I solder a 12MHz clock instead of the PL611 in my design. Result is the same (after changing oscillator to 12Mhz in XN file): USB unknow device.
Then back to the vanila config with PL611 and run the tools you provide, here the results (with custom audio app):

Information for device USB\Vendor_0000_Product_0000:

Connection Information:
------------------------------
Device current bus speed: FullSpeed
Device supports USB 1.1 specification
Device supports USB 2.0 specification
Device address: 0x0000
Current configuration value: 0x00
Number of open pipes: 0

Microsoft OS Descriptor is not available. Error code: 0x000001B1

String Descriptor Table
--------------------------------
Index LANGID String

------------------------------

Connection path for device:
Contrôleur d’hôte compatible xHCI USB
Root Hub
USB\Vendor_0000_Product_0000 Port: 9

Running on: Windows 10 or greater (Build Version 18363)

Brought to you by TDD v2.14.0, Apr 15 2020, 13:48:58

So :)
If I try to remenber how usb works, when we plug a usb low level start a USB1.1 session to negociate and see what device is and after can switch to UBS2 or 3.
Looks obvious issue start on USB1.1 session hmmm hw issue I think...
Will try a trick, solder directly a usb cable on the resistors near the XUF208 for D+/D- in my PCB in order to skeep my long lines and connector. Will try this tomorow as soon first time dragon crew flight and can't miss that :)
User avatar
mon2
XCore Legend
Posts: 1812
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Wed May 27, 2020 10:52 pm

Ok. After very much digging amongst the pile of kits in the lab, found the XMOS kit and made an attempt to run the same IP. Same issue as yours. Then rolled back the compiler and repeated the testing. Same issue. So the fault had to be somewhere else...

Please adjust your makefile and comment out the following line as shown:

Code: Select all

# These flags define two build configurations - one for U-series and one for
# the xCORE-200 series.

#XCC_FLAGS_U     = -Wall -O3 -report -DXUD_SERIES_SUPPORT=XUD_U_SERIES
XCC_FLAGS_X200  = -Wall -O3 -report -DXUD_SERIES_SUPPORT=XUD_X200_SERIES
Target here is the following (but use the CPU that you have on your PCB):

Code: Select all

XUF208-256-TQ128-C10
Please post your update after testing with the above change.

update:

Removed the older compiler from my Win10 box - again. Installed the latest toolchain from XMOS (14.4.1).

After the above makefile change, the HID Mouse IP works properly.
__BriKs__
Active Member
Posts: 39
Joined: Tue Nov 27, 2018 9:45 pm

Postby __BriKs__ » Wed May 27, 2020 11:14 pm

Did it, same results:

Information for device USB\Vendor_0000_Product_0000:

Connection Information:
------------------------------
Device current bus speed: FullSpeed
Device supports USB 1.1 specification
Device supports USB 2.0 specification
Device address: 0x0000
Current configuration value: 0x00
Number of open pipes: 0

Microsoft OS Descriptor is not available. Error code: 0x000001B1

String Descriptor Table
--------------------------------
Index LANGID String

------------------------------

Connection path for device:
Contrôleur d’hôte compatible xHCI USB
Root Hub
USB\Vendor_0000_Product_0000 Port: 9

Running on: Windows 10 or greater (Build Version 18363)

Brought to you by TDD v2.14.0, Apr 15 2020, 13:48:58

and my makefile:
# The TARGET variable determines what target system the application is
# compiled for. It either refers to an XN file in the source directories
# or a valid argument for the --target option when compiling.

# In this case, the target depends on the build configuration.
ifeq ($(CONFIG),X200)
TARGET = XUF208-256-TQ128-C10
else
TARGET = XUF208-256-TQ128-C10
endif

# The APP_NAME variable determines the name of the final .xe file. It should
# not include the .xe postfix. If left blank the name will default to
# the project name
APP_NAME = app_hid_mouse_demo

# The flags passed to xcc when building the application
# You can also set the following to override flags for a particular language:
#
# XCC_XC_FLAGS, XCC_C_FLAGS, XCC_ASM_FLAGS, XCC_CPP_FLAGS
#
# If the variable XCC_MAP_FLAGS is set it overrides the flags passed to
# xcc for the final link (mapping) stage.

# These flags define two build configurations - one for U-series and one for
# the xCORE-200 series.

#XCC_FLAGS_U = -Wall -O3 -g -report -DXUD_SERIES_SUPPORT=XUD_U_SERIES
XCC_FLAGS_X200 = -Wall -O3 -report -DXUD_SERIES_SUPPORT=XUD_X200_SERIES

# The USED_MODULES variable lists other module used by the application.
USED_MODULES = lib_usb

#=============================================================================
# The following part of the Makefile includes the common build infrastructure
# for compiling XMOS applications. You should not need to edit below here.

XMOS_MAKE_PATH ?= ../..
include $(XMOS_MAKE_PATH)/xcommon/module_xcommon/build/Makefile.common

Who is online

Users browsing this forum: No registered users and 6 guests