TWI scanner example stuck at address 0x1 on nRF51 DK board

[myNrfDoesntWork]

Hi,

i've got the TWI scanner example flashed onto the NRF51 dk board, using the default "Arduino" pins of P0.07 and P0.30 as SDA/SCL.

I've added two lines to the example code inside the "for each address loop" so that it reads out each address as it checks it, and the code is untouched otherwise.:

				NRF_LOG_INFO("scanning: 0x%x.\r\n", address);
				NRF_LOG_FLUSH(); // helps catch the 0x1 error further down

With nothing plugged in to P0.07 and P0.30, I get on the uart output:

APP:INFO:TWI scanner.
APP:INFO:scanning: 0x1.
APP:INFO:scanning: 0x2.
APP:INFO:scanning: 0x3.
APP:INFO:scanning: 0x4.
APP:INFO:scanning: 0x5.
APP:INFO:scanning: 0x6.
...
...
...
APP:INFO:scanning: 0x7d.
APP:INFO:scanning: 0x7e.
APP:INFO:scanning: 0x7f.
APP:INFO:No device was found.

On a board external to the DK, I have two i2c items on the sda/scl lines - one at address 0x40, and one at 0x38. The external devices is powered through the VDD on the DK board (I've also tried powering it externally, no difference), and the grounds between the external devices and the DK board are connected.

I've tried 5k both ohms and 10k ohms pullups on both the SDA/SCL lines, same deal.

The SDA/SCL lines are also tied to two separate NRF51822 (unpowered) i/o pins, not too sure if that does anything to this test.

If I plug in any single wire (SDA/SCL) into either P0.07 or P0.30, I get:

APP:INFO:TWI scanner.
APP:INFO:scanning: 0x1.

And that's it. It's stuck at 0x1.

The 0x1 line doesn't print if I don't force a flush immediately after printing that line.

Any ideas appreciated.

[Jørgen Holmefjord]

Hi,

Have you tried using other pins? P0.07 on the nRF51 DK is by default used for the CTS UART HW flow control line and connected to the interface MCU.

Did you debug the application, to see if it is only the log that does not output, or if the application crashes?

Best regards,
Jørgen

[myNrfDoesntWork]

Hi,

Yes, I've gone around and tried many pairs of pins. All the same behavior. What else do you suggest I try?

To address your second point, Keil has been having issues with debugging and flashing. I've never gotten it to work quite right. This happens 90% of the time I try: (Update: I've managed to fix the Keil issue and can do debugging now. Will try to add a debug log output shortly).

I've went through most of the options here:

When I just try to flash the code, sometimes Keil wants to connect to the nrf51-dk board and "download" the code, but I just go through nRF connect to do the flashing.

Thanks.

[Jørgen Holmefjord]

Please check using the debugger where the application is stopping. If you do not get more output, something seems to stop. You can also check the TWI lines using a logic analyzer, to see if anything is output on the bus.

[myNrfDoesntWork]

Ok, I got the debug working by going into Windows control panel -> repair nrf toolkit. Why would a new installation require this step is beyond me.

Anyways, the debugger does help - it gets stuck at a while loop that it never seems to exit within nrf_drv_twi.marked by the breakpoint. 

That line of code calls this below, which seemingly returns true all the time (at least 200 times, anyways).

I'm in the situation where I am away from any of the usual debugging tools, with no oscilloscope and definitely no logic analyzer, so all I have is this debugger and a multimeter.

Do you have any suggestions on how to proceed? 

Thanks.

[Jørgen Holmefjord]

It is not easy to give suggestions without seeing a logic trace of the bus. It seems that there is not generated a STOPPED event. Which device did you connect to the TWI bus? Have you tried with other devices? I assume the devices are powered and run at a similar voltage to the nRF?

[myNrfDoesntWork]

Right, I don't have a good way to see a logic trace of the bus at the moment. I have a MAX7313 connected to the bus, address set to 0x40. It's supplied with 3.3V as well. I have a small collection of i2c devices on the bus that can be jumpered in (sda/scl disconnected). No luck on any of them. Supply is good to all devices.

I've ended up trying the sdk v10 examples, would you be able to tell me if the code will do what I think it will - namely sweep through all addresses and read out the first few registers of each?

//==========START example==================

#<included everything needed for this thing to compile>

void twi_init (void){
    ret_code_t err_code;
    

    //mma7660 is from the example, won't bother changing variable names.
    const nrf_drv_twi_config_t twi_mma_7660_config = {
       .scl                = 16,
       .sda                = 15,
       .frequency          = NRF_TWI_FREQ_100K,
       .interrupt_priority = APP_IRQ_PRIORITY_HIGH
    };
    
    err_code = nrf_drv_twi_init(&m_twi_mma_7660, &twi_mma_7660_config, twi_handler, NULL);
    APP_ERROR_CHECK(err_code);
    
    nrf_drv_twi_enable(&m_twi_mma_7660);
}

int main(void){
        uart_config();
        twi_init();
        uint8_t readResult = 0x00;
        ret_code_t rt;
        for(int adr = 0; adr< 128; ++adr){
            for(int i = 0; i<0xF; ++i){
                rt = nrf_drv_twi_rx(&m_twi_mma_7660, adr, &readResult, 1, false);
                nrf_delay_ms(100);
                printf("%d>>0x%d:%x\t%d\r\n",adr,i,readResult,rt);
            
            }
        }
    
    
    while(true){
                printf("done\r\n");
                nrf_delay_ms(500);
    }
}

//================END of example======================

I run that and end up getting error codes of 0, and readResults of 0 as well. But it runs and doesn't get stuck.

Thanks.