AN01027 i2c issue Topic is solved

If you have a simple question and just want an answer.
__BriKs__
Active Member
Posts: 39
Joined: Tue Nov 27, 2018 9:45 pm

Re: AN01027 i2c issue

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

Will investigate on electric layer, test to bypass my connector and a part of my pcb with a flying wire usb connector.

Update: sorry made a mistake I own a XUF208-256-TQ64-C10 instead of XUF208-256-TQ128-C10, then I test makefile with right cpu, no change.

# 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-TQ64-C10
else
TARGET = XUF208-256-TQ64-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

It's a custom PCB manual hand soldered then not strange some parts will don't work first time. Will try usb flying wire cable tomorow.
View Solution
__BriKs__
Active Member
Posts: 39
Joined: Tue Nov 27, 2018 9:45 pm

Postby __BriKs__ » Thu May 28, 2020 10:01 am

Hello,

Try to solder a usb cable near the Xmos, same behavior (didn't work). Attached a screen of my solders and the Xtime project I use to test USB.
Results from usb tools:

Information for device USB\Vendor_0000_Product_0000:

Connection Information:
------------------------------
Device current bus speed: LowSpeed
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
Concentrateur USB générique
Concentrateur USB générique
USB\Vendor_0000_Product_0000 Port: 2

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

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

Mon2, can you send me a .xe files from your project (with a build with target = XUF208-256-TQ64-C10) maybe I can try to run it with xrun command an see what appends?
You do not have the required permissions to view the files attached to this post.
User avatar
mon2
XCore Legend
Posts: 1829
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Thu May 28, 2020 11:47 am

Yes. Can share the compiled firmware in a few hours upon reaching the office.

Still concerned about the fact you are self powered and the USB handshake timing.

Our pcb under test is all powered by USB. However let us try this and a few other ideas.

You can use xtag to run a simple led blinky and that works to pulse a gpio pin on your PCB? We will do the same and share that as well for your testing.

Bye for now.
User avatar
mon2
XCore Legend
Posts: 1829
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Thu May 28, 2020 12:35 pm

While waiting, open the .XN file for this project (with a text editor) and change the following:

Code: Select all

  <Node Id="0" InPackageId="0" Type="XS2-L8A-256" Oscillator="24MHz" SystemFrequency="500MHz" referencefrequency="100MHz">
to

Code: Select all

  <Node Id="0" InPackageId="0" Type="XS2-L8A-256" SystemFrequency="500MHz" referencefrequency="100MHz">
Remove the Oscillator="24MHz". We too attempted to fix the non-working IP with this value but it did not make a difference. The makefile appeared to be the issue.

Will confirm in a few hours when we open (3 hours from now).
User avatar
mon2
XCore Legend
Posts: 1829
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Thu May 28, 2020 3:34 pm

Hi. Changed the target CPU to:

Code: Select all

TARGET = XUF208-256-TQ64-C10
inside the MAKEFILE.

Can you try the attached .xe file to see if it works on your custom PCBA with the same CPU?

The attachment is in zip format so please extract to use.
You do not have the required permissions to view the files attached to this post.
User avatar
mon2
XCore Legend
Posts: 1829
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Thu May 28, 2020 6:23 pm

Attached is the compiled binary for AN10018_flashing_leds with:

Code: Select all

TARGET = XUF208-256-TQ64-C10
Hard coded to toggle GPIO pin X0D37 = Pin 64 on your device.

Please confirm that this firmware is able to toggle this corner pin with high / low pattern.

Code: Select all

/**
Note that this function has been marked as '[[combinable]]'. This
means it can share a logical core with other combinable functions that
will handle other events in between the port outputs of this flashing
LED task.
**/

port p = XS1_PORT_1N; // for TQFP64 corner pin # 64  = X0D37 for easy access

int main() {
  par {
    flashing_led_task1(p, 500);
  //  flashing_led_task2(q, 300);
  }
  return 0;
}
This code is available from the XMOS supplied Examples tab inside the toolchain.
xmos_blinky.png
You do not have the required permissions to view the files attached to this post.
User avatar
mon2
XCore Legend
Posts: 1829
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Thu May 28, 2020 11:11 pm

Forgot to state earlier that a bit concerned about the use of the PLL611-01 PLL in the design. Although the PLL is noted to be programmable - to this day, not clear on how this device is programmed for custom clock rates. This could be an issue to investigate.

The USB IP demands that the CPU clock be 24 Mhz. Recommend to source a +3v3 CMOS fixed clock generator @ 24.00 Mhz - force the OE pin to be high on the oscillator and use it to mate with your CPU.

Very possible this PLL (due to lack of perhaps Microchip factory programming) is not spitting out of the desired 24 Mhz clock.

There is also the FSEL pin which may not be at the proper logic level to select the native input clock. Too many parameters that can halt this design from working. Test with a fixed clock oscillator as well.

http://ww1.microchip.com/downloads/en/D ... 611-01.pdf
__BriKs__
Active Member
Posts: 39
Joined: Tue Nov 27, 2018 9:45 pm

Postby __BriKs__ » Fri May 29, 2020 9:33 am

Hello mon2,

Issue still not resolved, here the results of homework:

- test without Oscillator 24Mhz in the NodeId=0 line of XN file : still unknow USB device without descriptor, then I test to also remove Oscillator 24Mhz from the line Node Od = 1 in the XN file (then the XN file as no reference to 24Mhz inside): still unknow USB device without descriptor
-test the APP_HID_MOUSE_DEMO_X200.zip you provided with "xrun app_hid_mouse_demo_X200.xe" : still unkwo USB device with no descriptor
-flashing led: this time I try to flash it and run it without XTAG3, then I use the commande "xflash -AN10018_flashing_leds.xe" and it works, see the attached scope screen with a beautifull square wave around 1Hz.

-Yesterday I try to remove R614 in order to clock the Xmos with a reference 12Mhz clock I have in stock (in fact a STM32 nucleo dev board, I use the Master Clock Out of STM32 to clock the Xmos, MCO of STM32 is derived from a crystal so enaugh accurate to feed an USB, off course I change XN file 24Mhz to 12Mhz clock, but still not change: usb unknow device descriptor failled)

-The PLL I use as the reference PL611-01-N12M, buy on digikey, wich is the refrence used in Xmos audio reference design. I probe with my scope the output CLK0 wich is supposed to be 24Mhz whatever status of pin FSEL, I saw a 24Mhz clock but very sinusoid shape instead of square. I doubt this is due to the limited bandwith of my probe (60Mhz) and scope (100Mhz). Then I measure an other 24Mhz reference clokc in my design (a Master Clock Out of the STM32 in the design), I saw same type of sinusoid shape instead of square, then I conclude the PL611 24Mhz shoud be fine beacuse I'm very confident in the Master Clock Out of STM32. Anyway can test with a faster scope in 2 weeks, will do, but I didn't saw anything impliyng bad clock from PL611. Note I don't try to feed Xmos clock with Master Clock Out of STM32 in my PCB because STM32 in mydesign have no quartz and a poort accuracy intern oscillator.

Then good news is my CPU seems to works even without debuger, so from flash, and I can use it to flash a led, also I learned a lot about using of Xtime and XRUN, XFLASH, when USB will work no doubt I can go quickly to a well custom audio app to perfectly fit my amp.

I have to accurate probe each voltage pin of Xmos in my custom PCB to see if there in no issue here, but this is a difficult task i'm afraid of doing shorts and frie the Xmos.
You do not have the required permissions to view the files attached to this post.
User avatar
mon2
XCore Legend
Posts: 1829
Joined: Thu Jun 10, 2010 11:43 am

Postby mon2 » Fri May 29, 2020 11:03 am

Try the following:

1) leave the USB cable attached to your PC and then run the IP. Concerned about the USB timing of a self powered device. If you flashed the pcba then connect the USB cable and power cycle your power supply.

2) run the following:

Code: Select all

xrun --dump-state --verbose your_app.xe
Where does this code hang?
__BriKs__
Active Member
Posts: 39
Joined: Tue Nov 27, 2018 9:45 pm

Postby __BriKs__ » Fri May 29, 2020 11:52 am

Yes,

C:\Users\Flo>xrun --dump-state --verbose hid.xe

Warning: XN11135 Attribute SystemFrequency is ignored when Oscillator is not specified.
C:/Users/User/AppData/Local/Temp/.xgdb1112-2SH8JEBB/platform.xn:30 Warning: XN11206 Oscillator is not specified for USB node.

***** Active Cores *****
3 tile[0] core[2] 0x00040e96 in XUD_DeviceAttachHS ()
2 tile[0] core[1] (dual issue) 0x00040e14 in XUD_ResetEndpoint ()
* 1 tile[0] core[0] 0x00041b00 in StoreTailLength ()

Thread 3 (tile[0] core[2]):

***** Call Stack *****
#0 0x00040e96 in XUD_DeviceAttachHS ()
#1 0x00041360 in XUD_Manager_loop ()
#2 0x0004168a in xud_ ()
#3 0x00041714 in _Sxud_0 ()
#4 0x000403fd in __main__main_tile_0_task_xud_0 ()
#5 0x00042810 in __start_core ()

***** Disassembly *****
0x40e96 <XUD_DeviceAttachHS+78>: out (r2r) res[r7], r6 *
0x40e98 <XUD_DeviceAttachHS+80>: sub (2rus) r1, r1, 0x1
0x40e9a <XUD_DeviceAttachHS+82>: bt (ru6) r1, -0x3
0x40e9c <XUD_DeviceAttachHS+84>: ldw (lru6) r1, dp[0x14e]
0x40ea0 <XUD_DeviceAttachHS+88>: setd (r2r) res[r1], r6

***** Registers *****
r0 0x201 513
r1 0x3e7e 15998
r2 0x2710 10000
r3 0x1 1
r4 0x1 1
r5 0x43088 274568
r6 0x0 0
r7 0x80000 524288
r8 0x1 1
r9 0x7f794 522132
r10 0x0 0
r11 0x2 2
cp 0x428e8 272616
dp 0x42a20 272928
sp 0x7f6d8 521944
lr 0x40e7c 265852 XUD_DeviceAttachHS + 52
pc 0x40e96 265878 XUD_DeviceAttachHS + 78
sr 0x40 64
spc 0x0 0
ssr 0x0 0
et 0x0 0
ed 0x201 513
sed 0x0 0
kep 0x40080 262272
ksp 0x0 0

Thread 2 (tile[0] core[1] (dual issue)):

***** Call Stack *****
#0 0x00040e14 in XUD_ResetEndpoint ()
#1 0x00040180 in Endpoint0 ()
#2 0x00040411 in __main__main_tile_0_task_Endpoint0_1 ()
#3 0x00042810 in __start_core ()

***** Disassembly *****
0x40e14 <XUD_ResetEndpoint+72>: in (2r) r0, res[r2] *
0x40e16 <XUD_ResetEndpoint+74>: nop (0r)
0x40e18 <XUD_ResetEndpoint+76>: in (2r) r0, res[r3] *
0x40e1a <XUD_ResetEndpoint+78>: nop (0r)
0x40e1c <XUD_ResetEndpoint+80>: bu (lu6) 0x1

***** Registers *****
r0 0x43388 275336
r1 0x43048 274504
r2 0x102 258
r3 0x302 770
r4 0x43008 274440
r5 0x7fd9c 523676
r6 0x43388 275336
r7 0x7fd9d 523677
r8 0xffffffff -1
r9 0x0 0
r10 0x0 0
r11 0x0 0
cp 0x428e8 272616
dp 0x42a20 272928
sp 0x7fd68 523624
lr 0x40180 262528 Endpoint0 + 100
pc 0x40e14 265748 XUD_ResetEndpoint + 72
sr 0x140 320
spc 0x0 0
ssr 0x0 0
et 0x0 0
ed 0x0 0
sed 0x0 0
kep 0x40080 262272
ksp 0x0 0

Thread 1 (tile[0] core[0]):

***** Call Stack *****
#0 0x00041b00 in StoreTailLength ()
#1 0x00040c70 in XUD_SetBuffer ()
#2 0xf002685e in ?? ()
Backtrace stopped: frame did not save the PC

***** Disassembly *****
0x41b00 <StoreTailLength+6>: testct (2r) r11, res[r10] *
0x41b02 <StoreTailLength+8>: bt (ru6) r11, 0xe
0x41b04 <StoreTailLength+10>: in (2r) r11, res[r10] *
0x41b06 <XUD_SetData_LoadEpType>: ldw (2rus) r11, r0[0x5]
0x41b08 <XUD_SetData_LoadEpType+2>: bf (ru6) r11, 0x6

***** Registers *****
r0 0x433b0 275376
r1 0x42f84 274308
r2 0x4304c 274508
r3 0x0 0
r4 0x1 1
r5 0x4 4
r6 0x42f80 274304
r7 0x0 0
r8 0x0 0
r9 0x1 1
r10 0x502 1282
r11 0x0 0
cp 0x428e8 272616
dp 0x42a20 272928
sp 0x7fed8 523992
lr 0x40c70 265328 XUD_SetBuffer + 16
pc 0x41b00 269056 StoreTailLength + 6
sr 0x40 64
spc 0x0 0
ssr 0x0 0
et 0x0 0
ed 0x0 0
sed 0x0 0
kep 0x40080 262272
ksp 0x0 0

C:\Users\Flo>

Note: when run with xrun --dump-sate --verbose hid.xe there is no windows notification about USB, when run only xrun hid.xe, there is windows USB notification (still as unknow device).
hid.xe is the build from config with makefile with "XCC_FLAGS_X200 = -Wall -O3 -report -DXUD_SERIES_SUPPORT=XUD_X200_SERIES"

Who is online

Users browsing this forum: No registered users and 4 guests