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.

AM6442: TI SDK api is not working as expected.

Part Number: AM6442

Hi,

I am using TI mcu_plus_sdk_am64x_09_00_00_31 and using to generate keywriter binary for my AM6442 device. There is a requirement of switching the EMMC hardware boot partition from the keywriter program for which I used the api provided by sdk 'MMCSD_enableBootPartition' but on passing the partition number as 2 the boot partition 2 was not enabled. So I wrote some functions to read and write the EXTCSD register index 179 to switch boot partitions manually. Attaching the screenshot of the implementation. With these implementations I am able to switch boot partition. Please review and suggest any modifications if implementation is not correct. image.png

image.png

image.png

Regards,

Ankur

  • Hello,

    If I compare your implemenation with the default MMCSD_enableBootPartition, I don't see any logical differences. Can you share the relevant logs showing the working case with your implementation and non-working case with the default MMCSD_enableBootPartition.

  • Hi Prashant,

    If I am using the sdk api the keywriter program is getting stuck most of the time, maybe due to timing issues. In my custom code I have better control as I have put sleep after read and write operations and it is running fine everytime. 

  • If I am using the sdk api the keywriter program is getting stuck most of the time,

    How do you check the device is stuck? Do you use the debugger and find that the application is stuck somewhere?

    In my custom code I have better control as I have put sleep after read and write operations and it is running fine everytime. 

    I am not aware about these R/W operations. Could you please elaborate more?

  • I have put debug logs in the keywriter application, on booting only partial logs are printed on console and then device does not responds. I must do power cycle to recover the device. This happens if I use sdk api MMCSD_enableBootPartition.

    As there is no api available to read the contents of EXTCSD register, I am sending MMC protocol command 8 from my application to read 512 bytes of EXTCSD register and then decoding the bits in 179 index to get the following parameter values     

    Bit 6: Boot ACK
    Bits 5-3: Boot Enable
    Bits 2-0: Partition Access

    To switch the boot partition I am modifying the above bits in 179 index of the EXTCSD register by sending MMC protocol command 6 from my application and then verifying the changes by again reading back. Boot Enable and Partition access bits must have value 1 or 2 for active boot partition as 1 or 2 respectively. Boot ACK is always 1. In case of using sdk api MMCSD_enableBootPartition the Partition Access bits were 0(only 1 or 2 times I saw as most of the times application hangs). As this operation is busy wait operation there may be timing or sync issues. If I use my custom functions the application finishes every time with desired output.  

  • In case of using sdk api MMCSD_enableBootPartition the Partition Access bits were 0(only 1 or 2 times I saw as most of the times application hangs). As this operation is busy wait operation there may be timing or sync issues. If I use my custom functions the application finishes every time with desired output. 

    But, I do not see any logical differences between your "manual_set_boot_partition" and the default "MMCSD_enableBootPartition". If there are any, could you please list those?

    As for the application hang, I believe it may just be caused by the UART. If you are using the keywriter v09.00.00, could you please change the mode from "Interrupt" to "Polled" for the UART and see it it least print the logs every time.

  • It will take some time for me to validate with the UART related changes but these should not affect the functionality. We have keywriter image in partition 1 of EMMC and Linux image in partition 2. The api call with input as partition 2 must change the boot partition on next reboot but everytime the device was booting with keywriter binary.

    I observed the following differences : SDK api is modifying the register index 177 also to set boot bus width. I have given extra 1 second delay after calling my function.

    I wanted to know that if we use our custom function to do the same will this cause any issue? We may modify our keywriter application in future to add some more functionality so if we keep it like that it will be helpful for us. We just wanted to get our changes in keywriter application to be reviewed. Let me know if it is correct to use the sdk to build our custom application. 

  • SDK api is modifying the register index 177 also to set boot bus width.

    This is required so you must also do the same in your implementation.

    I have given extra 1 second delay after calling my function.

    If this is working then you may do the same for the default SDK function.

    In any case, you may continue with your implementation but it should also modify the boot bus width similar to how it is modified in the default SDK function.

  • Hi Prashant,

    I configured the uart in polling mode and called the sdk api with delay, now I am seeing that the partition is switching. However I have observed inconsistency during multiple runs. The keywriter program stucks in between. I am using Teraterm to see the serial logs, when I disconnect and connect a new instance of teraterm the keywriter program runs fine but if I run mutiple times in same instance of teraterm the keywriter program stucks. So, uart mode might not be the root cause. Have you encountered similar issue earlier?  

  • Hello,

    Have you encountered similar issue earlier?

    We haven't tested such scenarios in the context of the keywriter.

    The keywriter program stucks in between.

    Could you please elaborate more on this? When this happens, could you please take the logs and share them? If possible, could you please use the debugger to check where the core is stuck?