• State
  • Locked Locked
  • Replies 3 replies
  • Subscribers 98 subscribers
  • Views 808 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM3703: Time jumps under special conditions

Michael Bubestinger
Prodigy 70 points
Other Parts Discussed in Thread: AM3703, TUSB1210

Hi,

I'm working on a custom am3703 based design, which shows a strange behaviour.

The software is based on Linux 2.6.32.

The board supports 3G and WiFi.

- connected via WiFi everything is fine

- connected via 3G everything is fine

- connected via GPRS and bad signal quality the problem occurs.

I can see 2 things, sometimes both at the same time:

- the time ( via 'date') jumps forward. 60% of these jumps are 2^17 , 131072 seconds. (edit: no rtc, only the internal linux timer module)

- 3G module disconnects from the USB core with following message:

[ 3725.886993] hub 1-0:1.0: port 2 disabled by hub (EMI?), re-enabling...

[ 3725.905426] usb 1-2: USB disconnect, address 2

[ 3725.918304] generic ttyUSB0: generic converter now disconnected from ttyUSB0

[ 3725.936340] usbserial_generic 1-2:1.0: device disconnected

[ 3725.957672] generic ttyUSB1: generic converter now disconnected from ttyUSB1

[ 3725.979309] usbserial_generic 1-2:1.1: device disconnected

[ 3726.016082] generic ttyUSB2: generic converter now disconnected from ttyUSB2

[ 3726.040435] usbserial_generic 1-2:1.2: device disconnected

[ 3726.062866] generic ttyUSB3: generic converter now disconnected from ttyUSB3

[ 3726.083557] usbserial_generic 1-2:1.3: device disconnected

[ 3726.108398] generic ttyUSB4: generic converter now disconnected from ttyUSB4

[ 3726.129089] usbserial_generic 1-2:1.4: device disconnected

A hardware reset of the 3G Module, via GPIOs doesn't help, but a reboot of the linux system with 'reboot' works. The module enumerats fine, while booting the system.

While searching on e2e for similar problems, I came across the errata "Delay Required to Read Some GP, WD, and Sync Timer Registers After Wake-Up" and fix for linux >3.0 (http://e2e.ti.com/support/embedded/linux/f/354/t/280122.aspx).  I couldn't find a backport to our version, so I tried to fix it by myself:

in arch/arm/plat-omap/dmtimer.c

#define OMAP_TIMER_NONPOSTED                   0x00

static void omap_dm_timer_reset(struct omap_dm_timer *timer)

omap_dm_timer_write_reg(timer, OMAP_TIMER_IF_CTRL_REG,OMAP_TIMER_CTRL_NONPOSTED);
timer->posted = 0;

This code should change the configuration of every timer to nonposted mode.
Im not sure if this fix does, what it is supposed to do. But i know it didn't work..the time jumps forward.

My next problem is, i can't see a link between a bad connection via GPRS, the disconnect and the time change.
Im not sure if I see 2 problems or one...

Do you have any ideas?

Thank you
Michael

  • 0
    TI__Guru 62875 points

    We have recently had a similar issue reported with product using a different TI processor and determined the issue was being caused by noise coupling into the crystal circuit.  This may be a similar issue where your GPRS transmitter is coupling into the crystal circuit and causing the oscillator to generate internal clock glitches.

    How do you have the crystal connected to the AM3703 processor?  If it is connected as shown in Figure 4-2 of the AM37xx Data Sheet, try to connect the sys_xtalgnd and crystal circuit component grounds to the nearest PCB digital ground to see if this resolves the issue.

    If this does not help, you need to shield the processor subsystem from the GPRS transmitter and filter any paths that could conduct emissions into the processor subsystem.

    Regards,
    Paul

  • 0 in reply to peaves
    Prodigy 70 points

    The crystal is already connected to the GND.

    AM3703, RAM and FLASH are on a seperate PCB and encapsulated. The USB-IF is provided by TUSB1210.

    Is there a possibility to get more information out of the EHCI Core? At the moment, I have no information why the module disconnects. I think this could give us the hint we need, to track down the problem.

    Regards,
    Michael

  • 0 in reply to Michael Bubestinger
    Prodigy 70 points

    We are working on a workaround for the timejump, but we are still looking for a real fix.
    Our application tries to detect the timejump, reads the rtc and set the "real" system time.

    Today i got an interesting output on the console, I don't know if it helps: (Client.arm is our userland-application)

             
[ 4703.912841] BUG: soft lockup - CPU#0 stuck for 286s! [Client.arm:331]
[ 4703.919372] Modules linked in: usbserial bt8xxx sd8xxx mcypt(P) pwm_beeper
[ 4703.926361]
[ 4703.927886] Pid: 331, comm:           Client.arm
[ 4703.932556] CPU: 0    Tainted: P            (2.6.32 #7)
[ 4703.937866] PC is at do_settimeofday+0xd0/0xe4
[ 4703.942352] LR is at do_settimeofday+0xb0/0xe4
[ 4703.946838] pc : [<c0086224>]    lr : [<c0086204>]    psr: 40000013
[ 4703.946868] sp : c72e7f60  ip : c0515680  fp : bee99a04
[ 4703.958404] r10: 40025000  r9 : c72e6000  r8 : c00380c4
[ 4703.963684] r7 : 80000013  r6 : c72e7f88  r5 : ad62e0df  r4 : c0515610
[ 4703.970275] r3 : 00000000  r2 : c72e7f60  r1 : 00773594  r0 : 00000001
[ 4703.976867] Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[ 4703.984039] Control: 10c5387d  Table: 8722c019  DAC: 00000015
[ 5854.296783] BUG: soft lockup - CPU#0 stuck for 287s! [Client.arm:331]
[ 5854.303283] Modules linked in: usbserial bt8xxx sd8xxx mcypt(P) pwm_beeper
[ 5854.310302]
[ 5854.311828] Pid: 331, comm:           Client.arm
[ 5854.316497] CPU: 0    Tainted: P            (2.6.32 #7)
[ 5854.321777] PC is at do_settimeofday+0xd0/0xe4
[ 5854.326293] LR is at do_settimeofday+0xb0/0xe4
[ 5854.330780] pc : [<c0086224>]    lr : [<c0086204>]    psr: 40000013
[ 5854.330780] sp : c72e7f60  ip : c0515680  fp : bee99a04
[ 5854.342346] r10: 40025000  r9 : c72e6000  r8 : c00380c4
[ 5854.347625] r7 : 80000013  r6 : c72e7f88  r5 : ad7ae4d6  r4 : c0515610
[ 5854.354217] r3 : 00000000  r2 : c72e7f60  r1 : 00773594  r0 : 00000001
[ 5854.360778] Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[ 5854.367980] Control: 10c5387d  Table: 8722c019  DAC: 00000015
[ 6196.396789] BUG: soft lockup - CPU#0 stuck for 286s! [Client.arm:331]
[ 6196.403320] Modules linked in: usbserial bt8xxx sd8xxx mcypt(P) pwm_beeper
[ 6196.410339]
[ 6196.411834] Pid: 331, comm:           Client.arm
[ 6196.416503] CPU: 0    Tainted: P            (2.6.32 #7)
[ 6196.421813] PC is at do_settimeofday+0xd0/0xe4
[ 6196.426300] LR is at do_settimeofday+0xb0/0xe4
[ 6196.430786] pc : [<c0086224>]    lr : [<c0086204>]    psr: 40000013
[ 6196.430816] sp : c72e7f60  ip : c0515680  fp : bee99a04
[ 6196.442382] r10: 40025000  r9 : c72e6000  r8 : c00380c4
[ 6196.447631] r7 : 80000013  r6 : c72e7f88  r5 : ad7eec9b  r4 : c0515610
[ 6196.454223] r3 : 00000000  r2 : c72e7f60  r1 : 00773594  r0 : 00000001
[ 6196.460815] Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[ 6196.468017] Control: 10c5387d  Table: 8722c019  DAC: 00000015
[ 6547.812225] BUG: soft lockup - CPU#0 stuck for 287s! [Client.arm:331]
[ 6547.818756] Modules linked in: usbserial bt8xxx sd8xxx mcypt(P) pwm_beeper
[ 6547.825775]
[ 6547.827270] Pid: 331, comm:           Client.arm
[ 6547.831939] CPU: 0    Tainted: P            (2.6.32 #7)
[ 6547.837249] PC is at do_settimeofday+0xd0/0xe4
[ 6547.841735] LR is at do_settimeofday+0xb0/0xe4
[ 6547.846221] pc : [<c0086224>]    lr : [<c0086204>]    psr: 40000013
[ 6547.846252] sp : c72e7f60  ip : c0515680  fp : bee99a04
[ 6547.857788] r10: 40025000  r9 : c72e6000  r8 : c00380c4
[ 6547.863067] r7 : 80000013  r6 : c72e7f88  r5 : ad85009b  r4 : c0515610
[ 6547.869659] r3 : 00000000  r2 : c72e7f60  r1 : 00773594  r0 : 00000001
[ 6547.876251] Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment user
[ 6547.883453] Control: 10c5387d  Table: 8722c019  DAC: 00000015

    Regards,

    Michael