My external UART driver don't work

Hi all.

Test_GPS_Driver.zip

I have a problem with a driver that I wrote (it's the first driver I do). I attach an example code.
If in the gps2_thread_entry.cpp comment the line 58 the gps1 works well. If I try to initialize both gps the program gets stuck in the gps_init function. The interrupts seem to overlap.
It's probably wrong the way I did the driver, but I don't understand where I'm wrong :(

Thank ypu

Paolo

  • In reply to Paolo Miatto:

    Hi.

     

    >I had to make some changes if not it didn't even run with one module. I attach the modified source.

    I just found out that GPS process thread independently starts GPS initialize thread.
    So I made another version from Test_gps_5a.

    This has expanded interrupt log also.

     

    >With one module enabled at a time, the system works. Enabling both it always seems to hang when the gps1 interrupt arrives after the gps2 interrupt.

    >In this case only the gps1 is processed and then it freezes (I have tried several times and from the logs the last ones are always like the attached image).

     

    You sets both priority of irq9 and irq14 to 12, and irq14 callback has fewer vector number than irq9 because of auto code generation, gps1 irq is prioritized over gps2 irq so far.
    Furthermore arm mcu always supports multiple interrupts.
    Thus gps1 irq intercepts gps2 irq handler.

    It cause malfunction, but I have not yet clarified how it occur.

    Can you try the newer version?

    Test_gps_5a2.zip

  • In reply to tenballs:

    Hi.

    I have tried your code.
    It seems that when two interrupts occurs the read function it remains in a loop (see attachment).

    Thank you for your support.

    Paolo

     

  • In reply to Paolo Miatto:

    Hi.

     

    >It seems that when two interrupts occurs the read function it remains in a loop (see attachment).

    Probably it loops endless in the while loop in uart_external_read() for some unknown reason.

    I expanded interrupt log again and add FIFORdy Log.

    Lets try the newer version and look into if the event "RX_BUF_ABNO_OVERLAP" occurs.

    If so, see FIFORdy_log[].

     

    Test_gps_5a3.zip 

  • In reply to tenballs:

    >Probably it loops endless in the while loop in uart_external_read() for some unknown reason.

    I agree

    I attach images of the logs. FIFORdy_log is all 34.

     

    Thanks

    Paolo

     

     

  • In reply to Paolo Miatto:

    Hi.

    >I attach images of the logs. FIFORdy_log is all 34.

    According to the manual, both bit 2 and 3 of FIFO Ready Register are always 0.

    Therefore, I think the reason for this is as follows.

    1. The code accesses invalid chip address.
    2. Can't access UART chip properly.
    3. UART chip runs away.

    Try newer version.
    It can monitor whether UART chip address is broken.

    If "IO_ADDR_BROKEN" event never occur, I am afraid to say you should recheck hardware signals.

    Test_gps_5a4.zip


    By the way, why do you set/reset bit 7 of LCR before and after IIR read?

    I can't find why that process is essential in the manual.

    ----------------------------------------------------------

    uint8_t r_tl16c752d_read_interrupt_reg(TL16C752D_REGISTER volatile * const reg)
    {
    uint8_t tmp_lcr = reg->LCR.VALUE.BYTE;
    reg->LCR.VALUE.BYTE &= 0x7F;

    uint8_t value = reg->IIR.VALUE.BYTE;

    // Set the old value of the LCR register
    reg->LCR.VALUE.BYTE = tmp_lcr;

    return value;
    }

    ----------------------------------------------------------

  • In reply to tenballs:

    Hi.

    >By the way, why do you set/reset bit 7 of LCR before and after IIR read?

    I reset/set LCR[7] because is need for access IIR register (see image)

     

    Now I test your code and let you know.

    Thanks

    Paolo

  • In reply to tenballs:

    >If "IO_ADDR_BROKEN" event never occur, I am afraid to say you should recheck hardware signals

    Never occur :(

    I'll check the signals with the oscilloscope.

    Thanks

    Paolo

  • In reply to Paolo Miatto:

    Hi tenball.
    I solved it.
    You were right, it was a hardware problem. I replaced the cs mux with a faster one and now it seems to work.

    Thank you
    Paolo