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.

WL1835MOD pre-built image trouble

Other Parts Discussed in Thread: WL1835MOD, WL1271

Hi, all. I'm trying to online a Beaglebone Black with the WL1835MOD cape (http://boardzoo.com/index.php/beaglebone/beaglebone-wl1835mod-w-chip-antenna.html#.VPcwGTW350w)

I'm using the pre-built image here:

https://gforge.ti.com/gf/download/user/6430/7236/tisdk-rootfs-image-am335x-evm-sdk7.0-ecs-tp-opt.tar.gz

as referenced here:

http://processors.wiki.ti.com/index.php/WL18xx_AMxxx_Platform_Integration_Guide

... using the am335x-boneblack.dtb tree against a Rev C Beaglebone Black with the WL1835MOD cape.

I decompiled the am335x-boneblack.dtb tree to check its mappings: kim => /dev/ttyO4, mmc2 enabled, etc... Everything looks sane to me on cursory inspection. However, I'm not getting any response from the device.

The cape LED's seem to indicate that power is not an issue, but I could be mistaken. Probing UART4's TX and RX lines shows data being transmitted at 115 kbaud, but no data being received. Probing the MMC is a bit more of a challenge, especially considering the presence of the EMMC, so I haven't analyzed that carefully. I'm additionally slightly alarmed at the power consumption of the device - we're pulling 5V/750 mA (and I think the Bone itself is powered off the USB), and so far as I can tell neither radio has been successfully activated.

Any advice? Has anyone gotten this image working with this cape (or any TI image with this hardware combination?)

Thanks and regards,

Greg

  • Hi,

     For BBB it is a bit tricky as unlike the BBW, the serial port doesn’t have a connector and you need to use a USB level shifter. see the post which should help you understand how to get an user interface to see what is happening from the terminal http://e2e.ti.com/support/wireless_connectivity/f/307/p/388831/1374547

    The pre-built images from the below link (same as the ones you have provided) are working fine, without any issue.

    https://gforge.ti.com/gf/download/user/6430/7079/tisdk-boot-am335x-evm-sdk7.0-ecs.tar.gz
    https://gforge.ti.com/gf/download/user/6430/7236/tisdk-rootfs-image-am335x-evm-sdk7.0-ecs-tp-opt.tar.gz

     

  • Hi, Sundeep,

    We had the electricals set up fine, it turns out the unit I had was fried. That also explains the 750 mA it was drawing and why it was so hot. We replaced it with an identical cape, which works with SDK7.

    I'm now trying to port the work over to a Debian Jessie base, using a slightly modified kernel 3.14 (currently based off of 3.14.31-ti-r49 as I recall.) The device tree fragment I'm using is:

    &am33xx_pinmux {
    /* wl12xx/wl18xx card on mmc1. Oh so is the EMMC. Neat. */
    mmc2_pins_default: pinmux_mmc2_pins_default {
    pinctrl-single,pins = <
    0x80 (PIN_INPUT_PULLUP | MUX_MODE2) /* gpmc_csn1.mmc1_clk */
    0x84 (PIN_INPUT_PULLUP | MUX_MODE2) /* gpmc_csn2.mmc1_cmd */
    0x00 (PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_ad0.mmc1_dat0 */
    0x04 (PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_ad1.mmc1_dat1 */
    0x08 (PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_ad2.mmc1_dat2 */
    0x0C (PIN_INPUT_PULLUP | MUX_MODE1) /* gpmc_ad3.mmc1_dat3 */
    >;
    };

    mmc2_pins_sleep: pinmux_mmc2_pins_sleep {
    pinctrl-single,pins = <
    0x80 (PIN_INPUT_PULLDOWN | MUX_MODE7) /* gpmc_csn1.mmc1_clk */
    0x84 (PIN_INPUT_PULLDOWN | MUX_MODE7) /* gpmc_csn2.mmc1_cmd */
    0x00 (PIN_INPUT_PULLDOWN | MUX_MODE7) /* gpmc_ad0.mmc1_dat0 */
    0x04 (PIN_INPUT_PULLDOWN | MUX_MODE7) /* gpmc_ad1.mmc1_dat1 */
    0x08 (PIN_INPUT_PULLDOWN | MUX_MODE7) /* gpmc_ad2.mmc1_dat2 */
    0x0C (PIN_INPUT_PULLDOWN | MUX_MODE7) /* gpmc_ad3.mmc1_dat3 */
    >;
    };
    };

    &mmc2 {
    status = "okay";
    vmmc-supply = <&wlan_en_reg>;
    bus-width = <4>;
    cap-power-off-card;
    keep-power-in-suspend;
    ti,non-removable;
    ti,needs-special-hs-handling;
    pinctrl-names = "default", "sleep";
    pinctrl-0 = <&mmc2_pins_default>;
    pinctrl-1 = <&mmc2_pins_sleep>;

    #address-cells = <1>;
    #size-cells = <0>;

    wlcore: wlcore@0 {
    compatible = "ti,wlcore";
    reg = <2>;
    interrupt-parent = <&gpio0>;
    interrupts = <27 0>; /* IRQ_TYPE_NONE */
    };
    };

    However, things are not going so well from here. After about 2 minutes, the kernel oops'es due to a timeout:
    [ 240.594611] INFO: task kworker/0:1:15 blocked for more than 120 seconds.
    [ 240.601705] Not tainted 3.14.31-symetrica00+ #129
    [ 240.620119] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
    [ 240.635308] kworker/0:1 D c0732208 0 15 2 0x00000000
    [ 240.642108] Workqueue: events request_firmware_work_func
    [ 240.665882] Backtrace:
    [ 240.668550] [<c0731ed0>] (__schedule) from [<c0732628>] (schedule+0x40/0x90)
    [ 240.685164] r10:dd9d4000 r9:00000000 r8:00000002 r7:c0ab650c r6:7fffffff r5:dd9d5cf8
    [ 240.693506] r4:c07330d0
    [ 240.699059] [<c07325e8>] (schedule) from [<c07318c0>] (schedule_timeout+0x200/0x274)
    [ 240.710355] [<c07316c0>] (schedule_timeout) from [<c07330d0>] (wait_for_common+0xa8/0x160)
    [ 240.721365] r10:dd9d4000 r9:00000000 r8:00000002 r7:dd9d4000 r6:dd9d5cf4 r5:dd9d5cf8
    [ 240.731140] r4:7fffffff
    [ 240.733837] [<c0733028>] (wait_for_common) from [<c07331a8>] (wait_for_completion+0x20/0x24)
    [ 240.744544] r10:00000001 r9:00000001 r8:dd9d5cf4 r7:c0b4bae0 r6:dd9d5ce4 r5:ddbd4800
    [ 240.752845] r4:ddbd4800
    [ 240.756529] [<c0733188>] (wait_for_completion) from [<c058913c>] (mmc_wait_for_req_done+0x5c/0x14c)
    [ 240.767375] [<c05890e0>] (mmc_wait_for_req_done) from [<c0589258>] (mmc_wait_for_req+0x2c/0x30)
    [ 240.777469] r8:ddbd8000 r7:00000002 r6:01fffe00 r5:dd9d5ce4 r4:ddbd4800
    [ 240.785505] [<c058922c>] (mmc_wait_for_req) from [<c0594b8c>] (mmc_io_rw_extended+0x400/0x490)
    [ 240.795478] r5:03ff8800 r4:00000004
    [ 240.799285] [<c059478c>] (mmc_io_rw_extended) from [<c0596330>] (sdio_io_rw_ext_helper+0x13c/0x1a8)
    [ 240.810305] r10:00000000 r9:db204204 r8:0001ffc4 r7:00000001 r6:ddbe6200 r5:00000000
    [ 240.818715] r4:00000004
    [ 240.821410] [<c05961f4>] (sdio_io_rw_ext_helper) from [<c0596518>] (sdio_memcpy_toio+0x30/0x38)
    [ 240.832223] r10:00000000 r9:0001ffc4 r8:00000000 r7:00000004 r6:db204200 r5:dddde210
    [ 240.840638] r4:ddbe6200
    [ 240.843346] [<c05964e8>] (sdio_memcpy_toio) from [<bf00f1f8>] (wl12xx_sdio_raw_write+0x98/0x1b4 [wlcore_sdio])
    [ 240.855644] [<bf00f160>] (wl12xx_sdio_raw_write [wlcore_sdio]) from [<bf1c3630>] (wlcore_set_partition+0xe0/0x4c8 [wlcore])
    [ 240.868690] r9:db012e40 r8:db001540 r7:bf1db1a0 r6:bf1d9cd8 r5:bf1fa9b0 r4:db28ee20
    [ 240.877093] [<bf1c3550>] (wlcore_set_partition [wlcore]) from [<bf1b61fc>] (wl12xx_set_power_on+0x80/0x130 [wlcore])
    [ 240.889550] r7:dddde200 r6:db204180 r5:00000000 r4:db28ee20
    [ 240.895714] [<bf1b617c>] (wl12xx_set_power_on [wlcore]) from [<bf1bdbdc>] (wlcore_nvs_cb+0x164/0x994 [wlcore])
    [ 240.907552] r5:bf1d9cd8 r4:db28ee20
    [ 240.911395] [<bf1bda78>] (wlcore_nvs_cb [wlcore]) from [<c04a30d0>] (request_firmware_work_func+0x40/0x60)
    [ 240.922864] r10:df9baf05 r9:dd9d4028 r8:00000000 r7:df9baf00 r6:df9b7dc0 r5:dd9bee80
    [ 240.931265] r4:db2041c0
    [ 240.933966] [<c04a3090>] (request_firmware_work_func) from [<c00634dc>] (process_one_work+0x134/0x458)
    [ 240.945621] r4:db2041c0
    [ 240.948331] [<c00633a8>] (process_one_work) from [<c00642cc>] (worker_thread+0x144/0x3d4)
    [ 240.958277] r10:c0b3872a r9:dd9d4000 r8:dd9d4028 r7:df9b7dd4 r6:dd9bee98 r5:df9b7dc0
    [ 240.966690] r4:dd9bee80
    [ 240.969386] [<c0064188>] (worker_thread) from [<c006a68c>] (kthread+0xdc/0xf4)
    [ 240.978589] r10:00000000 r9:00000000 r8:00000000 r7:c0064188 r6:dd9bee80 r5:dd9bd880
    [ 240.986987] r4:00000000
    [ 240.989681] [<c006a5b0>] (kthread) from [<c000fab8>] (ret_from_fork+0x14/0x20)
    [ 240.999023] r7:00000000 r6:00000000 r5:c006a5b0 r4:dd9bd880
    [ 257.355274] systemd[1]: Got notification message for unit systemd-journald.service
    [ 257.385088] systemd[1]: systemd-journald.service: got WATCHDOG=1

    With a little extra debugging tooling (plus adding some printk's with method names) I observe the boot cycle:
    [ 2.659752] mmc_rescan
    [ 2.668498] mmc_attach_sdio (mmc0)
    [ 2.672590] mmc_send_io_op_cond (mmc0)
    [ 2.678435] mmc_attach_sdio (mmc0) mmc_send_io_op_cond returned -110
    [ 2.789850] mmc_rescan
    [ 2.803112] mmc_attach_sdio (mmc1)
    [ 2.807143] mmc_send_io_op_cond (mmc1)
    [ 2.828690] mmc_sdio_init_card (mmc1)
    [ 2.840266] mmc_send_io_op_cond (mmc1)
    [ 3.064363] sdio mmc1:0001:1: sdio_add_func: set name mmc1:0001:1
    [ 3.080846] sdio mmc1:0001:2: sdio_add_func: set name mmc1:0001:2
    [ 12.804365] wl1271_init
    [ 13.713931] mmc_send_io_op_cond (mmc1)
    [ 13.842605] mmc_sdio_init_card (mmc1)
    [ 13.878418] mmc_send_io_op_cond (mmc1)
    [ 14.126144] wl1271_probe
    [ 14.564802] mmc_send_io_op_cond (mmc1)
    [ 14.654968] mmc_sdio_init_card (mmc1)
    [ 14.659291] mmc_send_io_op_cond (mmc1)
    [ 14.834468] wl1271_probe
    [ 16.805760] wl18xx_probe
    [ 18.069783] wl18xx_driver wl18xx.0.auto: wl12xx_sdio_set_power 1
    [ 18.194262] mmc_send_io_op_cond (mmc1)
    [ 18.199043] mmc_sdio_init_card (mmc1)
    [ 18.204399] mmc_send_io_op_cond (mmc1)
    [ 18.451347] mmc mmc1:0001: mmc_io_rw_extended write: 1 fn: 2 addr: 131012 incr_addr: 1 buf: db204200 blocks: 0 blksz: 4
    [ 18.465637] mmc mmc1:0001: mmc_io_rw_extended cmd 53 a7ff8804 data blksz 4 blocks 1
    [ 18.476227] omap_hsmmc_do_irq status 1
    [ 18.480765] omap_hsmmc_dma_callback req_in_progress 1
    [ 19.874365] omap_hsmmc_do_irq status 108000

    The oops is because neither the DMA nor the IRQ callback (both of which are invoked) ever call omap_hsmmc_request_done when this sequence of events occurs.

    I don't really think this sequence of events is *supposed* to occur, but hard to tell.

    I'm not really sure where to go from here. I'm not familiar enough with MMC to debug this effectively. I notice you guys are writing up a section on 3.14 integration on the Wiki - any idea when that'll be online?

    Thanks and regards,
    Greg