• State
  • Locked Locked
  • Replies 4 replies
  • Subscribers 98 subscribers
  • Views 113 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.

Original question:

TDA4AEN-Q1: TDA4AEN-Q1_[722S]MCAL FLS module adapts to external Flash

TDA4AEN-Q1: TDA4AEN-Q1_[722S]MCAL FLS Questions about FLs module

Gao Dingqing
Prodigy 50 points

Part Number: TDA4AEN-Q1

1 Debugging found a bug in the Fls_Brd_NOR. c interface of the MCAL driver Fls_Brd_NOR. c where the next write was performed without checking if the flash was complete, resulting in occasional data write failures. Solution: After each completion, check the flash status. The code circled below is the solution, following the approach of XSPI. Is this modification reasonable?
image.png
 
 2 Prerequisite: The Fls_Test. c and Fls_Irq. c files were not used After compiling the Fls_Test. c file and the Fls_Irq. c file, during debugging, after the CPU Reset operation, 1 It is not located in the HwiP'armv7r_vectors_nortos_Sm. S file, but in the Fls_Test. c file. 2 Cannot set breakpoints in the HwiP'armv7r_vectors_nortos_Sm. S file, it will be located in the Fls_Test. c file. After the Fls_Test. c file and the Fls_Irq. c file are not compiled, during debugging, after the CPU Reset operation, 1 Locate the -vectors of the HwiP'armv7r_vectors_nortos_Sm. S file. 2 You can set breakpoints in the HwiP'armv7r_vectors_nortos_asm. S file.
 
Problem: I hope to find the cause of phenomenon 1?
 
image.png
 
  • 0
    TI__Guru 61626 points

    Hello,

    sorry for the delay. I was out of office last week and i will check and get back to you.

    Regards

    Tarun Mukesh

  • 0
    Prodigy 50 points

    Hello,

    When will you come back?

  • 0 in reply to Gao Dingqing
    TI__Guru 61626 points

    Hello,

    I will check and reply back with in mid of next week.

    Regards

    Tarun Mukesh

  • 0 in reply to Tarun Mukesh Puvvada
    TI__Guru 61626 points

    Hello Gao Dingqing,

    Gao Dingqing said:
    1 Debugging found a bug in the Fls_Brd_NOR. c interface of the MCAL driver Fls_Brd_NOR. c where the next write was performed without checking if the flash was complete, resulting in occasional data write failures. Solution: After each completion, check the flash status. The code circled below is the solution, following the approach of XSPI. Is this modification reasonable?

    This looks reasonable to me , Fls_Brd_NOR.c is custom changeable since it is not part of FLS driver it is part of board flash folder . 

    Gao Dingqing said:
    The Fls_Test. c and Fls_Irq. c files were not used After compiling the Fls_Test. c file and the Fls_Irq. c file, during debugging, after the CPU Reset operation, 1 It is not located in the HwiP'armv7r_vectors_nortos_Sm. S file, but in the Fls_Test. c file. 2 Cannot set breakpoints in the HwiP'armv7r_vectors_nortos_Sm. S file, it will be located in the Fls_Test. c file. After the Fls_Test. c file and the Fls_Irq. c file are not compiled, during debugging, after the CPU Reset operation, 1 Locate the -vectors of the HwiP'armv7r_vectors_nortos_Sm. S file. 2 You can set breakpoints in the HwiP'armv7r_vectors_nortos_asm. S file.

    I dont understand this . HwiP'armv7r_vectors_nortos_Sm. S  and Fls_Test. c are not TI provided files but only Fls_Irq.c file is TI provided one.

    Regards

    Tarun Mukesh