Help! ADC 'stopped working' overnight

GoogleGroups
1

Hi everybody,
for a university project I’m using a bbb with Linux 3.8.13 bone49, for a couple of months I was acquiring analog input using the internal adc of the beaglebone and the pruss, using as a starting point Derek Molloy’s example (exploringbeaglebone/chapter13) and ADCCollector.c /ADCCollector.p files, basically I sample the signal at tevery front end of a pru clock with a fixed frequency.

Before running my program I always load the two overlays EBB-PRU-Example.dtbo and BB-ADC.dtbo and modprobe uio_pruss.

I’ve no idea what’s happened yesterday night but today I’m not able anymore to get coerents values from the ADC (AIN0 and ground), with a positive sinusoid of 1 V module I’m getting values that after the conversion (*1.8/4095) are around 11 V. The code has not being modified andI’m 100% that strangely enough the problem is not in the prus overlay, since I’m monitoring the ‘sampling-clock’ using an oscilloscope.

Any idea about what is going on?
/
I’ve rebooted and resetted the bbb, removed and loaded the overlays, I don’t have the /sys/devices/platform/tsc directory and doing:

cat: /sys/bus/iio/devices/iio:device0/in_voltage: No such file or directory.

dmesg:
root@arm:/home/debian# dmesg
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Initializing cgroup subsys cpu
[ 0.000000] Linux version 3.8.13-bone49 (root@imx6q-wandboard-2gb-0) (gcc ver sion 4.6.3 (Debian 4.6.3-14) ) #1 SMP Fri May 2 06:36:13 UTC 2014
[ 0.000000] CPU: ARMv7 Processor [413fc082] revision 2 (ARMv7), cr=50c5387d
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing instructio n cache
[ 0.000000] Machine: Generic AM33XX (Flattened Device Tree), model: TI AM335x BeagleBone
[ 0.000000] Memory policy: ECC disabled, Data cache writeback
[ 0.000000] On node 0 totalpages: 130816
[ 0.000000] free_area_init_node: node 0, pgdat c0828540, node_mem_map c08a300 0
[ 0.000000] Normal zone: 1024 pages used for memmap
[ 0.000000] Normal zone: 0 pages reserved
[ 0.000000] Normal zone: 129792 pages, LIFO batch:31
[ 0.000000] AM335X ES1.0 (neon )
[ 0.000000] PERCPU: Embedded 9 pages/cpu @c0cb3000 s14080 r8192 d14592 u36864
[ 0.000000] pcpu-alloc: s14080 r8192 d14592 u36864 alloc=9*4096
[ 0.000000] pcpu-alloc: [0] 0
[ 0.000000] Built 1 zonelists in Zone order, mobility grouping on. Total pag es: 129792
[ 0.000000] Kernel command line: console=ttyO0,115200n8 capemgr.disable_partn o=BB-BONELT-HDMI,BB-BONELT-HDMIN,BB-SPI01-01 root=UUID=df5f218f-c512-4a0a-84fd-9 224c752d1e9 ro rootfstype=ext4 rootwait fixrtc ip= quiet init=/lib/systemd/syste md
[ 0.000000] PID hash table entries: 2048 (order: 1, 8192 bytes)
[ 0.000000] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 0.000000] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[ 0.000000] __ex_table already sorted, skipping sort
[ 0.000000] allocated 1048576 bytes of page_cgroup
[ 0.000000] please try ‘cgroup_disable=memory’ option if you don’t want memor y cgroups
[ 0.000000] Memory: 511MB = 511MB total
[ 0.000000] Memory: 506200k/506200k available, 18088k reserved, 0K highmem
[ 0.000000] Virtual kernel memory layout:
vector : 0xffff0000 - 0xffff1000 ( 4 kB)
fixmap : 0xfff00000 - 0xfffe0000 ( 896 kB)
vmalloc : 0xe0800000 - 0xff000000 ( 488 MB)
lowmem : 0xc0000000 - 0xe0000000 ( 512 MB)
pkmap : 0xbfe00000 - 0xc0000000 ( 2 MB)
modules : 0xbf800000 - 0xbfe00000 ( 6 MB)
.text : 0xc0008000 - 0xc0766d14 (7548 kB)
.init : 0xc0767000 - 0xc07a2700 ( 238 kB)
.data : 0xc07a4000 - 0xc082b500 ( 542 kB)
.bss : 0xc082b500 - 0xc08a2c40 ( 478 kB)
[ 0.000000] Hierarchical RCU implementation.
[ 0.000000] RCU restricting CPUs from NR_CPUS=4 to nr_cpu_ids=1.
[ 0.000000] NR_IRQS:0 nr_irqs:0 0
[ 0.000000] IRQ: Found an INTC at 0xfa200000 (revision 5.0) with 128 interrup ts
[ 0.000000] Total of 128 interrupts on 1 active controller
[ 0.000000] OMAP clockevent source: GPTIMER1 at 24000000 Hz
[ 0.000000] sched_clock: 32 bits at 24MHz, resolution 41ns, wraps every 17895 6ms
[ 0.000000] OMAP clocksource: GPTIMER2 at 24000000 Hz
[ 0.000000] Console: colour dummy device 80x30
[ 0.000243] Calibrating delay loop… 993.47 BogoMIPS (lpj=969728)
[ 0.029175] pid_max: default: 32768 minimum: 301
[ 0.029320] Security Framework initialized
[ 0.029380] Mount-cache hash table entries: 512
[ 0.035641] Initializing cgroup subsys cpuacct
[ 0.035665] Initializing cgroup subsys memory
[ 0.035706] Initializing cgroup subsys blkio
[ 0.035796] CPU: Testing write buffer coherency: ok
[ 0.036189] CPU0: thread -1, cpu 0, socket -1, mpidr 0
[ 0.036244] Setting up static identity map for 0x8045fa10 - 0x8045fa5c
[ 0.037283] Brought up 1 CPUs
[ 0.037298] SMP: Total of 1 processors activated (993.47 BogoMIPS).
[ 0.038030] devtmpfs: initialized
[ 0.047076] omap_hwmod: wd_timer2: _wait_target_disable failed
[ 0.099319] pinctrl core: initialized pinctrl subsystem
[ 0.099457] rstctl core: initialized rstctl subsystem
[ 0.099803] regulator-dummy: no parameters
[ 0.100133] NET: Registered protocol family 16
[ 0.100751] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.106496] pinctrl-single 44e10800.pinmux: 142 pins at pa f9e10800 size 568
[ 0.107087] platform 49000000.edma: alias fck already exists
[ 0.107105] platform 49000000.edma: alias fck already exists
[ 0.107119] platform 49000000.edma: alias fck already exists
[ 0.107811] gpiochip_add: registered GPIOs 0 to 31 on device: gpio
[ 0.107910] OMAP GPIO hardware version 0.1
[ 0.108769] gpiochip_add: registered GPIOs 32 to 63 on device: gpio
[ 0.109538] gpiochip_add: registered GPIOs 64 to 95 on device: gpio
[ 0.110288] gpiochip_add: registered GPIOs 96 to 127 on device: gpio
[ 0.110557] of_get_named_gpio_flags exited with status 52
[ 0.110575] gpio-rctrl rstctl.4: loaded OK
[ 0.113972] hw-breakpoint: debug architecture 0x4 unsupported.
[ 0.115282] cpsw.0: No hwaddr in dt. Using 90:59:af:54:90:40 from efuse
[ 0.115301] cpsw.1: No hwaddr in dt. Using 90:59:af:54:90:42 from efuse
[ 0.124084] bio: create slab at 0
[ 0.130879] edma-dma-engine edma-dma-engine.0: TI EDMA DMA engine driver
[ 0.131032] of_get_named_gpio_flags: can’t parse gpios property
[ 0.131160] vmmcsd_fixed: 3300 mV
[ 0.132814] SCSI subsystem initialized
[ 0.133065] usbcore: registered new interface driver usbfs
[ 0.133130] usbcore: registered new interface driver hub
[ 0.133334] usbcore: registered new device driver usb
[ 0.134585] omap_i2c 44e0b000.i2c: bus 0 rev0.11 at 400 kHz
[ 0.135577] input: tps65217_pwr_but as /devices/ocp.3/44e0b000.i2c/i2c-0/0-00 24/input/input0
[ 0.137223] DCDC1: at 1500 mV
[ 0.138070] vdd_mpu: 925 <–> 1325 mV at 1325 mV
[ 0.138944] vdd_core: 925 <–> 1150 mV at 1125 mV
[ 0.139769] LDO1: at 1800 mV
[ 0.140624] LDO2: at 3300 mV
[ 0.142142] LDO3: 1800 mV
[ 0.143017] LDO4: at 3300 mV
[ 0.143750] tps65217 0-0024: TPS65217 ID 0xe version 1.2
[ 0.144210] omap_i2c 44e0b000.i2c: unable to select pin group
[ 0.144753] omap_i2c 4819c000.i2c: bus 1 rev0.11 at 100 kHz
[ 0.146165] omap_i2c 4819c000.i2c: unable to select pin group
[ 0.146309] media: Linux media interface: v0.10
[ 0.146442] Linux video capture interface: v2.00
[ 0.146521] pps_core: LinuxPPS API ver. 1 registered

2

You need to see what raw values are being read out of the ADC. If they’re higher than 4095, then you’ve got a problem - Which I’d guess would be a bad ADC.

Passed that . . .

voltage = ( raw_value / 4095 ) * scale

Where scale = highest possible voltage to be read in. Then of course max voltage on the ADC must not exceed 1.8v, ever.

Anyway, I figure you probably know most of this already, but do need to know that raw values over 4095 is very likely going to be bad news . . .

3

Yes I know about the conversion raw values-> real values, two days ago the raw values where in the range0-2000 as they should have been, now they are way way higher

4

OK, so define “way higher”. Higher than 4095 ?

5

Anyway, two possibilities here if the raw values are higher than 4095.

  1. Your ADC need to be calibrated. I believe there is info in the TRM on this, but I have yet to fully understand this process myself. So see the TRM for details.

  2. your ADC is damaged, and very likely irreversibly.

6

Higher like 40k, in the firt piat i wrote that the “translated” value is 11 volt.
But it’s variable, start from 0 and then invrease. Or somethime it’s all zeroes, or only numbers repeated like 11 12 14 all over again

7

OK, so another possibility does come to mind. The values you’re reading are somehow becoming corrupt before you check them. So humor me here, and honestly this is probably in your best interest anyhow. . .

  1. Reset your board, which is to say, reboot it, and make sure none of your stuff for the ADC loads at boot.
  2. Follow my guide here, but keep in mind it is based on 4.x kernels. So adjustments may have to be made http://www.embeddedhobbyist.com/2015/10/beaglebone-black-ad
  3. Use the sysfs method of reading values out of the ADC, single shot to double check raw values.

So, again, my guide above is meant for kernels 4.x but should work for the most part. File locations, and in where to echo to load capes is different, and I’m not sure what else. The point is that you need an alternate way of testing your ADC, and making sure it is not somehow your code. Let me know if this fixes the values read out, and if it does, we’ll have to pour through your code.

8

Just in case this somehow helps. ADC values are represented in a 32bit bit field. But this bitfield actually has 3 fields inside of it. You can double check to make sure I’m remembering correctly. But the first 12 bits is the actual ADC value, the next 4 bits is the ADC identifier( channel ), and the last 16 bits is “reserved”, meaning it’s not used.

SO if your bit alignment has somehow gone out of alignment . . . this could very well explain high / bad raw values.

9

Anyway, two possibilities here if the raw values are higher than 4095.

1) Your ADC need to be calibrated. I believe there is info in the TRM on
this, but I have yet to fully understand this process myself. So see the
TRM for details.

2) your ADC is damaged, and very likely irreversibly.

3) 4096?

If the registers are 16 bits, can the result be (by program) shifted
to be left justified or right justified? In many microprocessors this
is possible. If it's left justified, then > 4096 is just about
guaranteed.

Harvey

10
  1. It’s zero based, so 0 is counted too. The bitfield is LSB as far as I’m aware, but just standard bit manipulation in C should present no problems. As I’ve experienced none myself.
11

Apologies for the delay,
I spilled coffee on my notebook and it died.

BBB rebooted

root@arm:/home/debian# ls /lib/firmware/ | grep ADC
BB-ADC-00A0.dtbo

root@arm:/home/debian# sudo sh -c “echo ‘BB-ADC’ > /sys/devices/bone_capemgr.9/slots”

root@arm:~# dmesg | grep BB-ADC
[ 214.438002] bone-capemgr bone_capemgr.9: part_number ‘BB-ADC’, version ‘N/A’
[ 214.438290] bone-capemgr bone_capemgr.9: slot #7: ‘Override Board Name,00A0,Override Manuf,BB-ADC’
[ 214.438792] bone-capemgr bone_capemgr.9: slot #7: Requesting part number/version based 'BB-ADC-00A0.dtbo
[ 214.444710] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware ‘BB-ADC-00A0.dtbo’ for board-name ‘Override Board Name’, version ‘00A0’
[ 214.444798] bone-capemgr bone_capemgr.9: slot #7: dtbo ‘BB-ADC-00A0.dtbo’ loaded; converting to live tree

root@arm:~# lsmod
Module Size Used by
g_multi 47670 0
libcomposite 14299 1 g_multi
arc4 1660 2
rtl8192cu 73560 0
rtlwifi 63798 1 rtl8192cu
rtl8192c_common 51523 1 rtl8192cu
mac80211 411868 3 rtlwifi,rtl8192c_common,rtl8192cu
cfg80211 344277 2 mac80211,rtlwifi
rfkill 16656 2 cfg80211
uio_pruss 3865 0

no adc module!
but there is an entrz in the devices durectorz, so I think the module has been loaded correctly:
root@arm:/sys/bus/iio/devices/iio:device0# ls
dev in_voltage2_raw in_voltage5_raw name uevent
in_voltage0_raw in_voltage3_raw in_voltage6_raw power
in_voltage1_raw in_voltage4_raw in_voltage7_raw subsystem
with no input:
root@arm:/sys/bus/iio/devices/iio:device0# cat in_voltage0_raw
3760

compiling test.c with time iI got the awaited result:
…
3883 3898 3914 3912 3918 3913 3913 3919 3914 3916
real 3.826 user 0.002 sys 2.639 pcpu 69.01

So I guess the problem lies in the program…

12

well, if you have issues finding the bug, post the code. I’m sure someone will be able to spot / find it.

13

Apologies for the delay,
I spilled coffee on my notebook and it died.

BBB rebooted

root@arm:/home/debian# ls /lib/firmware/ | grep ADC
BB-ADC-00A0.dtbo

root@arm:/home/debian# sudo sh -c "echo 'BB-ADC' >
/sys/devices/bone_capemgr.9/slots"

root@arm:~# dmesg | grep BB-ADC
[ 214.438002] bone-capemgr bone_capemgr.9: part_number 'BB-ADC', version
'N/A'
[ 214.438290] bone-capemgr bone_capemgr.9: slot #7: 'Override Board
Name,00A0,Override Manuf,BB-ADC'
[ 214.438792] bone-capemgr bone_capemgr.9: slot #7: Requesting part
number/version based 'BB-ADC-00A0.dtbo
[ 214.444710] bone-capemgr bone_capemgr.9: slot #7: Requesting firmware
'BB-ADC-00A0.dtbo' for board-name 'Override Board Name', version '00A0'
[ 214.444798] bone-capemgr bone_capemgr.9: slot #7: dtbo 'BB-ADC-00A0.dtbo'
loaded; converting to live tree

root@arm:~# lsmod
Module Size Used by
g_multi 47670 0
libcomposite 14299 1 g_multi
arc4 1660 2
rtl8192cu 73560 0
rtlwifi 63798 1 rtl8192cu
rtl8192c_common 51523 1 rtl8192cu
mac80211 411868 3 rtlwifi,rtl8192c_common,rtl8192cu
cfg80211 344277 2 mac80211,rtlwifi
rfkill 16656 2 cfg80211
uio_pruss 3865 0

no adc module!
but there is an entrz in the devices durectorz, so I think the module has
been loaded correctly:

$ cat patches/defconfig | grep CONFIG_TI_AM335X_ADC
CONFIG_TI_AM335X_ADC=y

root@arm:/sys/bus/iio/devices/iio:device0# ls
dev in_voltage2_raw in_voltage5_raw name uevent
in_voltage0_raw in_voltage3_raw in_voltage6_raw power
in_voltage1_raw in_voltage4_raw in_voltage7_raw subsystem
with no input:
root@arm:/sys/bus/iio/devices/iio:device0# cat in_voltage0_raw
3760

compiling test.c with time iI got the awaited result:
......
3883 3898 3914 3912 3918 3913 3913 3919 3914 3916
real 3.826 user 0.002 sys 2.639 pcpu 69.01

So I guess the problem lies in the program..

Regards,