On Thu, Sep 26, 2013 at 11:16 AM, luke.leighton luke.leighton@gmail.com wrote:
- find out why the AXP209 is randomly shutting off (could be floating reset?)
*sigh* this turns out to be because (AGAIN) wits-tech did not... AGAIN ... tell us that they'd made changes which were NOT authorised, to the EOMA68-A20 CPU Card schematics.
this time what they've done is wire the 5V (ACIN) directly to the USB-OTG line of the AXP209.
*deep breath*.... the consequences of that are that when the device is being powered by USB-OTG, 5V appears on the EOMA68 5V power lines.
the consequences of _that_ are that the flying squirrel I/O board (which has its own AXP209 and a 5V step-up regulator to turn IPSOUT into a stable 5.0V output) fights with the incoming 5V power... and loses the moment that the voltage fluctuates by even the smallest amount (such as the A20 doing anything resembling the slightest amount of processing).
if wits-tech had fucking well told me what they were doing i could have put in a MOSFET or other power regulator on the I/O board to cope with power-in as well as power-out.
not entirely sure what to do here, i'll have to think about it. as far as testing the flying squirrel is concerned i can get it working (in a rather painful laborious way) by disconnecting USB-OTG: i've verified that the CPU Card can in fact be powered by *incoming* 5V power from the I/O board... i might need to cut one of the micro-usb cables i have here and remove its 5V line or something.
l.
Sent from my iPhone
On Sep 28, 2013, at 8:26 AM, "luke.leighton" luke.leighton@gmail.com wrote:
On Thu, Sep 26, 2013 at 11:16 AM, luke.leighton luke.leighton@gmail.com wrote:
- find out why the AXP209 is randomly shutting off (could be floating reset?)
*sigh* this turns out to be because (AGAIN) wits-tech did not... AGAIN ... tell us that they'd made changes which were NOT authorised, to the EOMA68-A20 CPU Card schematics.
this time what they've done is wire the 5V (ACIN) directly to the USB-OTG line of the AXP209.
*deep breath*.... the consequences of that are that when the device is being powered by USB-OTG, 5V appears on the EOMA68 5V power lines.
the consequences of _that_ are that the flying squirrel I/O board (which has its own AXP209 and a 5V step-up regulator to turn IPSOUT into a stable 5.0V output) fights with the incoming 5V power... and loses the moment that the voltage fluctuates by even the smallest amount (such as the A20 doing anything resembling the slightest amount of processing).
if wits-tech had fucking well told me what they were doing i could have put in a MOSFET or other power regulator on the I/O board to cope with power-in as well as power-out.
I don't have time to read everything, but we are putting an FPF3040 Power Distribution/Management Switch on the MEBv2 to handle this issue.
not entirely sure what to do here, i'll have to think about it. as far as testing the flying squirrel is concerned i can get it working (in a rather painful laborious way) by disconnecting USB-OTG: i've verified that the CPU Card can in fact be powered by *incoming* 5V power from the I/O board... i might need to cut one of the micro-usb cables i have here and remove its 5V line or something.
l.
arm-netbook mailing list arm-netbook@lists.phcomp.co.uk http://lists.phcomp.co.uk/mailman/listinfo/arm-netbook Send large attachments to arm-netbook@files.phcomp.co.uk
On Sat, Sep 28, 2013 at 6:46 PM, Christopher christopher@firemothindustries.com wrote:
if wits-tech had fucking well told me what they were doing i could have put in a MOSFET or other power regulator on the I/O board to cope with power-in as well as power-out.
I don't have time to read everything, but we are putting an FPF3040 Power Distribution/Management Switch on the MEBv2 to handle this issue.
chris, couple of things:
1) what's the S.E.-Asia equivalent of that part, so that the MEBv2 will be cost-effective?
2) there are a number of other people, reading this list, who are designing products. would it be ok if i asked you, should you find any rather important things like this, if you could take just a couple of minutes as-and-when you find them, to let everyone know?
thanks chris.
l.
https://github.com/allwinner-ics/device_softwinner_common/blob/master/hardwa...
argh. without telling me the tablet designers replaced the mba250 with an mxc6225. *sigh*. well, at least the driver's loaded and puts things up in /dev/input/event0
l.
On Sat, 2013-09-28 at 14:26 +0100, luke.leighton wrote:
On Thu, Sep 26, 2013 at 11:16 AM, luke.leighton luke.leighton@gmail.com wrote:
- find out why the AXP209 is randomly shutting off (could be floating reset?)
*sigh* this turns out to be because (AGAIN) wits-tech did not... AGAIN ... tell us that they'd made changes which were NOT authorised, to the EOMA68-A20 CPU Card schematics.
The best way to deal with 'QA' issues to factories in Far East is to say thank you for what you receive and request changes to the board that puts right whatever is a problem. This makes the whole process blameless and work gets done more quickly.
Testing yesterday I found cubieboard2 and eoma both draw power from the RS232 debug line tx,rx,gnd wires and keep themselves alive between reboots in ways that are totally unexpected.
At a first guess, this problem needs a 74hc08 or similar device wired as buffer to prevent signals doing things they are not supposed to do.
On Mon, Sep 30, 2013 at 9:17 AM, joem joem@martindale-electric.co.uk wrote:
On Sat, 2013-09-28 at 14:26 +0100, luke.leighton wrote:
On Thu, Sep 26, 2013 at 11:16 AM, luke.leighton luke.leighton@gmail.com wrote:
- find out why the AXP209 is randomly shutting off (could be floating reset?)
*sigh* this turns out to be because (AGAIN) wits-tech did not... AGAIN ... tell us that they'd made changes which were NOT authorised, to the EOMA68-A20 CPU Card schematics.
The best way to deal with 'QA' issues to factories in Far East is to say thank you for what you receive and request changes to the board that puts right whatever is a problem. This makes the whole process blameless and work gets done more quickly.
good advice. i'm finding that my associates believe that there is some sort of "contract" (as a quote to create a finished product) rather than a work-for-hire R&D ongoing set of payments. they're therefore blaming the chinese design team for failing to "abide by the contract".
but the more important issue we have here however is that to correct these problems requires cash to do another small run, to test the corrections. we can't drop 2.5k units into production without them being fully tested.
l.
On Mon, 2013-09-30 at 11:20 +0100, luke.leighton wrote:
On Mon, Sep 30, 2013 at 9:17 AM, joem joem@martindale-electric.co.uk wrote:
On Sat, 2013-09-28 at 14:26 +0100, luke.leighton wrote:
On Thu, Sep 26, 2013 at 11:16 AM, luke.leighton luke.leighton@gmail.com wrote:
- find out why the AXP209 is randomly shutting off (could be floating reset?)
*sigh* this turns out to be because (AGAIN) wits-tech did not... AGAIN ... tell us that they'd made changes which were NOT authorised, to the EOMA68-A20 CPU Card schematics.
The best way to deal with 'QA' issues to factories in Far East is to say thank you for what you receive and request changes to the board that puts right whatever is a problem. This makes the whole process blameless and work gets done more quickly.
good advice. i'm finding that my associates believe that there is some sort of "contract" (as a quote to create a finished product) rather than a work-for-hire R&D ongoing set of payments. they're therefore blaming the chinese design team for failing to "abide by the contract".
I assume the associates have never done business in Far East and carry on as if they are doing business in west as if it will get them results :)
You need to train them Luke. People work differently in different parts of world. The correct way to deal with Far East is to say thank you to the factory boss with a big gift for the items sent. Be happy. And then sort out any issues. :)
Never bring up words like 'contract'. The moment a factory owner decide to help you with big projects, they are like life partners and 'contract' mean nothing to no one.
but the more important issue we have here however is that to correct these problems requires cash to do another small run, to test the corrections. we can't drop 2.5k units into production without them being fully tested.
Why not do what the Far East always does well.
Make 10. If that works make 100. If that works make 1000. If that works make 100,000. If that works make 1,000,000. .. and keep on making until it no longer works as well as it used to, and then cut back. Start new products and production asap to keep up the revenue flow.
On Mon, Sep 30, 2013 at 12:03 PM, joem joem@martindale-electric.co.uk wrote:
I assume the associates have never done business in Far East and carry on as if they are doing business in west as if it will get them results :)
they've never done *technical* business in the far east.
You need to train them Luke.
well, what i'm having to do instead is let them see the consequences of them overriding my advice, because they're quotes more experienced quotes than i am so tend to weight my advice with a zero rating.
it's... very interesting to hear that you recommend the kind of advice that i'd naturally / instinctively would follow [except for getting upset when they don't follow explicit instructions and don't tell me what they have and haven't done]...
l.
On Mon, 2013-09-30 at 12:24 +0100, luke.leighton wrote:
On Mon, Sep 30, 2013 at 12:03 PM, joem joem@martindale-electric.co.uk wrote:
I assume the associates have never done business in Far East and carry on as if they are doing business in west as if it will get them results :)
they've never done *technical* business in the far east.
You need to train them Luke.
well, what i'm having to do instead is let them see the consequences of them overriding my advice, because they're quotes more experienced quotes than i am so tend to weight my advice with a zero rating.
been there, done that, just stick to your position without saying "i told you so", and they will eventually see it your way. And even if they didn't your future projects are not infected with their insanity.
it's... very interesting to hear that you recommend the kind of advice that i'd naturally / instinctively would follow [except for getting upset when they don't follow explicit instructions and don't tell me what they have and haven't done]...
Don't get upset. Always say thank you for what you received, and send it back as request for more modifications, and add to it some test results and photos that cover your point instead of relying on instructions and verbose commands. Dan Quale was a failed politician when he said "Verbosity makes things unclear". He would have made a great production engineer had he marched up and down a production line saying that!!!!
Sometimes it takes several attempts because the bundles of production files and miles of paperwork being handed up and down the chain is flawed. Its not anyone's fault.
well... this is _sort_ of progress... a 1.5k resistor is missing from the USB+ line on the STM32F, which, when added, resulted in the exact same error being created when the exact same software was uploaded to the Port103R demo board.
at this point it can be reasonably concluded that the STM32F software being uploaded to both boards, to get USB working, is shagged. which is odd, because i had it working a few weeks back [on the Port103R].
l.
Oct 2 16:05:41 localhost kernel: [2829651.641936] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Oct 2 16:05:41 localhost kernel: [2829651.641943] usb 1-1.4: Product: HID Demo Oct 2 16:05:41 localhost kernel: [2829651.641948] usb 1-1.4: Manufacturer: Black Sphere Technologies Oct 2 16:05:41 localhost kernel: [2829651.641953] usb 1-1.4: SerialNumber: DEMO Oct 2 16:05:41 localhost kernel: [2829651.643699] input: Black Sphere Technologies HID Demo as /devices/pci0000:00/0000:00:1d.7/usb1/1-1/1-1.4/1-1.4:1.0/input/input55 Oct 2 16:05:41 localhost kernel: [2829651.643903] generic-usb 0003:0483:5710.0030: input,hidraw7: USB HID v1.00 Mouse [Black Sphere Technologies HID Demo] on usb-0000:00:1d.7-1.4/input0 Oct 2 16:05:42 localhost kernel: [2829652.924274] usb 1-1.4: reset full-speed USB device number 72 using ehci_hcd Oct 2 16:05:42 localhost kernel: [2829652.996291] usb 1-1.4: device descriptor read/64, error -32 Oct 2 16:05:42 localhost kernel: [2829653.172291] usb 1-1.4: device descriptor read/64, error -32 Oct 2 16:05:42 localhost kernel: [2829653.348275] usb 1-1.4: reset full-speed USB device number 72 using ehci_hcd Oct 2 16:05:42 localhost kernel: [2829653.420284] usb 1-1.4: device descriptor read/64, error -32 Oct 2 16:05:43 localhost kernel: [2829653.596291] usb 1-1.4: device descriptor read/64, error -32 Oct 2 16:05:43 localhost kernel: [2829653.772290] usb 1-1.4: reset full-speed USB device number 72 using ehci_hcd Oct 2 16:05:43 localhost kernel: [2829654.180018] usb 1-1.4: device not accepting address 72, error -32 Oct 2 16:05:43 localhost kernel: [2829654.252288] usb 1-1.4: reset full-speed USB device number 72 using ehci_hcd Oct 2 16:05:44 localhost kernel: [2829654.660048] usb 1-1.4: device not accepting address 72, error -32 Oct 2 16:05:44 localhost kernel: [2829654.661392] usb 1-1.4: USB disconnect, device number 72 Oct 2 16:05:44 localhost kernel: [2829654.760280] usb 1-1.4: new full-speed USB device number 73 using ehci_hcd Oct 2 16:05:44 localhost kernel: [2829654.832266] usb 1-1.4: device descriptor read/64, error -32 Oct 2 16:05:44 localhost kernel: [2829655.008394] usb 1-1.4: device descriptor read/64, error -32 Oct 2 16:05:44 localhost kernel: [2829655.184394] usb 1-1.4: new full-speed USB device number 74 using ehci_hcd Oct 2 16:05:44 localhost kernel: [2829655.256412] usb 1-1.4: device descriptor read/64, error -32 Oct 2 16:05:44 localhost kernel: [2829655.432267] usb 1-1.4: device descriptor read/64, error -32 Oct 2 16:05:45 localhost kernel: [2829655.608391] usb 1-1.4: new full-speed USB device number 75 using ehci_hcd Oct 2 16:05:45 localhost kernel: [2829656.016073] usb 1-1.4: device not accepting address 75, error -32 Oct 2 16:05:45 localhost kernel: [2829656.088262] usb 1-1.4: new full-speed USB device number 76 using ehci_hcd Oct 2 16:05:46 localhost kernel: [2829656.496048] usb 1-1.4: device not accepting address 76, error -32 Oct 2 16:05:46 localhost kernel: [2829656.496420] hub 1-1:1.0: unable to enumerate USB device on port 4
On Wed, Oct 2, 2013 at 4:09 PM, luke.leighton luke.leighton@gmail.com wrote:
well... this is _sort_ of progress... a 1.5k resistor is missing from the USB+ line on the STM32F, which, when added, resulted in the exact same error being created when the exact same software was uploaded to the Port103R demo board.
at this point it can be reasonably concluded that the STM32F software being uploaded to both boards, to get USB working, is shagged. which is odd, because i had it working a few weeks back [on the Port103R].
solved! there's a bug in libopencm3 related to systick
i now have USB working and can start on audio, woo!
On Wed, Oct 2, 2013 at 10:15 PM, luke.leighton luke.leighton@gmail.com wrote:
On Wed, Oct 2, 2013 at 4:09 PM, luke.leighton luke.leighton@gmail.com wrote:
well... this is _sort_ of progress... a 1.5k resistor is missing from the USB+ line on the STM32F, which, when added, resulted in the exact same error being created when the exact same software was uploaded to the Port103R demo board.
at this point it can be reasonably concluded that the STM32F software being uploaded to both boards, to get USB working, is shagged. which is odd, because i had it working a few weeks back [on the Port103R].
solved! there's a bug in libopencm3 related to systick
i now have USB working and can start on audio, woo!
yippeee! ok, this is just a start - it's not reading the ADC (just playing a sine wave... badly... sounds more like a square wave...) but it's isochronous audio out, thanks to a patch to libopencm3 from apalmer.
$ arecord -D iec8:CARD=Bridge,DEV=0 -f S16_LE -c 2 -r 32000 -t voc out.voc
$ lsusb -v Bus 001 Device 028: ID cafe:cafe Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 1.00 bDeviceClass 0 (Defined at Interface level) bDeviceSubClass 0 bDeviceProtocol 0 bMaxPacketSize0 64 idVendor 0xcafe idProduct 0xcafe bcdDevice 1.00 iManufacturer 1 Innovative Converged Devices iProduct 2 Cantaloupe USB<>CAN Bridge iSerial 3 714702344364438323FF5D50 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 100 bNumInterfaces 2 bConfigurationValue 1 iConfiguration 0 bmAttributes 0x80 (Bus Powered) MaxPower 100mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 1 Audio bInterfaceSubClass 1 Control Device bInterfaceProtocol 0 iInterface 0 AudioControl Interface Descriptor: bLength 9 bDescriptorType 36 bDescriptorSubtype 1 (HEADER) bcdADC 1.00 wTotalLength 40 bInCollection 1 baInterfaceNr( 0) 1 AudioControl Interface Descriptor: bLength 12 bDescriptorType 36 bDescriptorSubtype 2 (INPUT_TERMINAL) bTerminalID 1 wTerminalType 0x0201 Microphone bAssocTerminal 2 bNrChannels 1 wChannelConfig 0x0001 Left Front (L)
arm-netbook@lists.phcomp.co.uk
-
Christopher -
joem -
luke.leighton