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.

TDA4VM: Cannot access COMPUTE_CLUSTER0_DRU_QUEUE from mcu2_0 after u-boot upgrade 7.3 to 8.x

Part Number: TDA4VM


Hi Ti,

I got an application running on mcu2_0 which gets loaded and started by u-boot rproc. This application access the "COMPUTE_CLUSTER0_DRU_QUEUE" (0x006D008000).

Here is the code which access in the end the register (csl_dru.c)

int32_t CSL_druQueueConfig(const CSL_DRU_t             *pRegs,
                           uint32_t                     queueId,
                           const CSL_DruQueueConfig    *queueCfg)
{
    int32_t     retVal = CSL_PASS;
    uint64_t    regVal;

    if((queueId >= CSL_DRU_NUM_QUEUE) || (NULL == queueCfg))
    {
        retVal = CSL_EFAIL;
    }
    else
    {
        regVal =  CSL_FMK(DRU_QUEUE_CFG_PRI, queueCfg->priority);
        regVal |= CSL_FMK(DRU_QUEUE_CFG_QOS, queueCfg->qos);
        regVal |= CSL_FMK(DRU_QUEUE_CFG_ORDERID, queueCfg->orderId);
        regVal |= CSL_FMK(DRU_QUEUE_CFG_CONSECUTIVE_TRANS,
                          queueCfg->consecuitveTrans);
        regVal |= CSL_FMK(DRU_QUEUE_CFG_REARB_WAIT, queueCfg->rearbWait);
        CSL_REG64_WR(&pRegs->DRUQueues.CFG[queueId], regVal);
    }

    return (retVal);
}

The problem is, that after upgrading u-boot from PSDK-Linux (7.3) to 8.x, it seems this register is not writeable anymore from the mcu2_0. The quoted ti dru driver code fails at CSL_REG64_WR call.

I suspect that something changed in the u-boot versions and somehow this (and more) registers are write protected for some cores.

Can you please tell me what the restricted access has caused and how I could change that?

The same application tries also to access PCIe specific address range (0x1000 0000 - 0x17ff ffff) which also fails now. I think the root cause is the same as at the COMPUTE_CLUSTER0_DRU_QUEUE register.

Any help is highly welcomed.
Best regards,
Thomas

PS: This can also be checked quickly via CCS. Just boot u-boot 7.3 and then connect to mcu2_0. Try to write access COMPUTE_CLUSTER0_DRU_QUEUE. It works.

Do the same with u-boot 8.x (8.04 for example) and you will get a message like this: "MAIN_Cortex_R5_0_0: Trouble Writing Memory Block at 0x6d008000 on Page 0 of Length 0x4: (Error -1065 @ 0x0) Unable to access device memory. Verify that the memory address is in valid memory. If error persists, confirm configuration, power-cycle board, and/or try more reliable JTAG settings (e.g. lower TCLK). (Emulation package 9.9.0.00040)"

  • Hi Thomas,

    Strange, DRU should be accessible from R5F. I see there is an DRU memory to memory transfer example available in PDK UDMA example in file packages\ti\drv\udma\examples\udma_dru_test\udma_dru_test.c. This file internally calls Udma_druQueueConfig to configure DRU queues and this example is working on mcu2_0, so it should be accessible from TIFS point of view. So can you please check this example first? 

    Rgds,

    Brijesh

  • Hello Brijesh,

    I build the udma_dru_direct_tr_testapp_freertos example via make -s BOARD=j721e_evm CORE=mcu2_0 udma_dru_direct_tr_testapp_freertos.

    Suspecting that this example is build for the SBL, I just copied the .xerf5 file to replace the mcu2_0 firmware, which gets load by SPL (u-boot): thomas@tda4vmx:~/e3mn/lib/firmware$ cp ~/tda4vmx/psdk/pdk_jacinto_08_04_00_21/packages/ti/binary/udma_dru_direct_tr_testapp_freertos/bin/j721e_evm/udma_dru_direct_tr_testapp_freertos_mcu2_0_release.xer5f j7-main-r5f0_0-fw

    I doubled checked the memory map of udma_dru_direct_tr_testapp_freertos_mcu2_0_release, and it seems that it uses a chunk of memory at the start of DDR. I just hope that it does not conflict with the u-boot memory for the sake of this test.

    UDMA DRU Direct TR application started...

    UDMA DRU memcpy using Direct TR15 block copy Passed!!

    All tests have passed!!

    The UART-Output shows me, that the udma_dru testapp has run fine. Very good news. Also when I connect now with CCS on MCU2_0 I can read/write on

    COMPUTE_CLUSTER0_DRU_QUEUE successfully.

    I think I will analyze what differs from the udma_dru testapp to my code. My udma-dru code run fine with PSDK-L 7.x. If you have anything in your mind which can push me in the right direction, please share it.

    Update: I missed that I'm currently using U-Boot from PSDKL 7.3. So I will redo the test as soon as I can replace with U-Boot from PSDKL 8.04

    Thank you and happy new year!
    Thomas

  • Happy New Year to you as well Thomas. Sure please check with the correct uboot. 

    Regards,

    Brijesh

  • Hi Brijesh,

    I tested it again with the correct uboot (PSDKL 8.04). The udma_dru_direct_tr_testapp_freertos application crashes and hangs in the HwiP_data_abort_handler_c.

    This is the only output on the UART when running the application:

    UDMA DRU Direct TR application started...
    

    Please verify this on your side. I think its the same issue as i described at my first post. Any help is highly appreciated, since its blocking our progress...

    Best regards,
    Thomas

  • Hi Thomas,

    I dont see issue in accessing these registers, atleast in the no-boot mode. I used SDK8.4 and i could access these registers from CCS memory window from mcu2_0..

    Regards,

    Brijesh 

  • Hi Brijesh,

    yes, with no-boot mode there is also no issue at my side. The issue occurs when you use u-boot as bootloader. Could you please verify this?

    Best regards,
    Thomas

  • Hi Thomas,

    Even when booting uboot on A72, i see these registers are accessible from mcu2_0 CCS window. 

    I used SDK8.4 to check, can you also please the latest release? 

    Regards,

    Brijesh

  • Good morning Brijesh,

    that is strange. Can we please verify that we are using the same software/test procedure?

    I use exactly this PSDKL: https://www.ti.com/tool/download/PROCESSOR-SDK-LINUX-J721E/08.04.00.11
    I saw today, that there is a new version (08.05), which I did not test yet.

    To setup the "boot-from-sd-card", I copied "tiboot3.bin tispl.bin u-boot.img sysfw.itb" from ti-processor-sdk-linux-j7-evm-08_04_00_11/board-support/prebuilt-images/ to the sd-card.

    Then I basically boot, and change the u-boot settings for a static IP address, and that it should receive the r5-firmware images via NFS.

    This is the output I get on main UART when booting up:

    U-Boot SPL 2021.01-ga169f42610 (Aug 30 2022 - 09:35:44 +0000)                                              
    Model: Texas Instruments K3 J721E SoC                                                                      
    Board: J721EX-PM2-SOM rev E7                                                                               
    SYSFW ABI: 3.1 (firmware rev 0x0008 '8.4.1--v08.04.01 (Jolly Jellyfi')                                     
    Trying to boot from MMC2                                                                                   
    Starting ATF on ARM64 core...             
                                                         
    NOTICE:  BL31: v2.6(release):v2.7-rc0-dirty                                                                
    NOTICE:  BL31: Built : 09:18:58, Aug 30 2022                                                               
    I/TC:                                                
    I/TC: OP-TEE version: 3.17.0-125-g15a746d28 (gcc version 9.2.1 20191025 (GNU Toolchain for the A-profile A4
    I/TC: WARNING: This OP-TEE configuration might be insecure!                                                
    I/TC: WARNING: Please check https://optee.readthedocs.io/en/latest/architecture/porting_guidelines.html    
    I/TC: Primary CPU initializing                                                                             
    I/TC: SYSFW ABI: 3.1 (firmware rev 0x0008 '8.4.1--v08.04.01 (Jolly Jellyfi')
    I/TC: HUK Initialized                                                                                      
    I/TC: Activated SA2UL device                                                                               
    I/TC: Enabled firewalls for SA2UL TRNG device                                                              
    I/TC: SA2UL TRNG initialized                         
    I/TC: SA2UL Drivers initialized     
    I/TC: Primary CPU switching to normal world boot     
                                                         
    U-Boot SPL 2021.01-ga169f42610 (Aug 30 2022 - 09:20:07 +0000)         
    Model: Texas Instruments K3 J721E SoC                                                                      
    Board: J721EX-PM2-SOM rev E7         
    SYSFW ABI: 3.1 (firmware rev 0x0008 '8.4.1--v08.04.01 (Jolly Jellyfi')      
    Detected: J7X-BASE-CPB rev E3                                                                              
    Detected: J7X-VSC8514-ETH rev E2                     
    Trying to boot from MMC2                             
                              
                                                         
    U-Boot 2021.01-ga169f42610 (Aug 30 2022 - 09:20:07 +0000)                             
                                                                                                               
    SoC:   J721E SR1.0 GP                                                                                      
    Model: Texas Instruments K3 J721E SoC                                                                      
    Board: J721EX-PM2-SOM rev E7                                                                               
    DRAM:  4 GiB                                                                                               
    Flash: 0 Bytes                                                                                             
    MMC:   sdhci@4f80000: 0, sdhci@4fb0000: 1                                                                  
    Loading Environment from FAT... OK                                                                         
    In:    serial@2800000                                                                                      
    Out:   serial@2800000                                
    Err:   serial@2800000                                
    am65_cpsw_nuss ethernet@46000000: K3 CPSW: nuss_ver: 0x6BA00101 cpsw_ver: 0x6BA80100 ale_ver: 0x00293904 P0
    Detected: J7X-BASE-CPB rev E3                                                                              
    Detected: J7X-VSC8514-ETH rev E2                     
    cdns,sierra serdes@5000000: sierra probed                                                                  
    Net:   eth0: ethernet@46000000port@1                                                                       
    Hit any key to stop autoboot:  0                                                                           
    switch to partitions #0, OK                                                                                
    mmc1 is current device                                                                                     
    SD/MMC found on device 1                                                                                   
    Failed to load 'boot.scr'                                                                                  
    0 bytes read in 0 ms                                                                                       
    Loaded env from uEnv.txt                                                                                   
    Importing environment from mmc1 ...                                                                        
    k3_r5f_rproc r5f@41000000: Core 1 is already in use. No rproc commands work
    k3_r5f_rproc r5f@41400000: Core 2 is already in use. No rproc commands work
    k3-navss-ringacc ringacc@2b800000: Ring Accelerator probed rings:286, gp-rings[96,20] sci-dev-id:235
    k3-navss-ringacc ringacc@2b800000: dma-ring-reset-quirk: disabled                                   
    am65_cpsw_nuss_port ethernet@46000000port@1: K3 CPSW: rflow_id_base: 2    
    ethernet@46000000port@1 Waiting for PHY auto negotiation to complete... done
    link up on port 1, speed 1000, full duplex                                                                 
    Using ethernet@46000000port@1 device                                                                       
    File transfer via NFS from server 192.168.1.2; our IP address is 192.168.1.5
    Filename '/home/thomas/e3mc_2//lib/firmware/j7-main-r5f0_0-fw'.             
    Load address: 0x82000000                                                              
    Loading: #################################################################
             #################################################################
             #################################################################
             #################################################################
             #################################################################
             #################################################################
             #####################################
    done                                                 
    Bytes transferred = 2182864 (214ed0 hex)
    Load Remote Processor 2 with data@addr=0x82000000 2182864 bytes: Success!
    am65_cpsw_nuss_port ethernet@46000000port@1: K3 CPSW: rflow_id_base: 2
    link up on port 1, speed 1000, full duplex
    Using ethernet@46000000port@1 device
    File transfer via NFS from server 192.168.1.2; our IP address is 192.168.1.5
    Filename '/home/thomas/e3mc_2//lib/firmware/j7-main-r5f0_1-fw'.
    Load address: 0x82000000                             
    Loading: *** ERROR: File lookup fail
    
    done                                                 
    am65_cpsw_nuss_port ethernet@46000000port@1: K3 CPSW: rflow_id_base: 2
    link up on port 1, speed 1000, full duplex
    Using ethernet@46000000port@1 device
    File transfer via NFS from server 192.168.1.2; our IP address is 192.168.1.5
    Filename '/home/thomas/e3mc_2//lib/firmware/j7-c71_0-fw'.
    Load address: 0x82000000                             
    Loading: *** ERROR: File lookup fail
    
    done                                                 
    am65_cpsw_nuss_port ethernet@46000000port@1: K3 CPSW: rflow_id_base: 2
    link up on port 1, speed 1000, full duplex
    Using ethernet@46000000port@1 device
    File transfer via NFS from server 192.168.1.2; our IP address is 192.168.1.5
    Filename '/home/thomas/e3mc_2//lib/firmware/j7-c66_0-fw'.
    Load address: 0x82000000                             
    Loading: *** ERROR: File lookup fail
    
    done                                                 
    0 - Name:'r5f@41000000' type:'internal memory mapped' supports: load start stop reset 
    1 - Name:'r5f@41400000' type:'internal memory mapped' supports: load start stop reset 
    2 - Name:'r5f@5c00000' type:'internal memory mapped' supports: load start stop reset 
    3 - Name:'r5f@5d00000' type:'internal memory mapped' supports: load start stop reset 
    4 - Name:'r5f@5e00000' type:'internal memory mapped' supports: load start stop reset 
    5 - Name:'r5f@5f00000' type:'internal memory mapped' supports: load start stop reset 
    6 - Name:'dsp@4d80800000' type:'internal memory mapped' supports: load start stop reset 
    7 - Name:'dsp@4d81800000' type:'internal memory mapped' supports: load start stop reset 
    8 - Name:'dsp@64800000' type:'internal memory mapped' supports: load start stop reset 
    am65_cpsw_nuss_port ethernet@46000000port@1: K3 CPSW: rflow_id_base: 2
    link up on port 1, speed 1000, full duplex
    Using ethernet@46000000port@1 device
    TFTP from server 192.168.1.2; our IP address is 192.168.1.5
    Filename 'e3mc/Image-e3mc.bin'.
    Load address: 0x82000000                             
    Loading: #T ################################################################
             #################################################################
             #################################################################
             #################################################################
             #################################################################
             #################################################################
             #################################################################
             #################################################################
             #################################################################
             #################################################################
             #################################################################
             #################################################################
             #################################################################
             #################################################################
             #################################################################         #################################################################
             #################################################################
             #################################################################
             #################################################################
             #################################################################
             #################################################################
             #################################################################
             #################################################################
             ######################
             837.9 KiB/s                                 
    done                                                 
    Bytes transferred = 19411456 (1283200 hex)
    am65_cpsw_nuss_port ethernet@46000000port@1: K3 CPSW: rflow_id_base: 2
    link up on port 1, speed 1000, full duplex
    Using ethernet@46000000port@1 device
    TFTP from server 192.168.1.2; our IP address is 192.168.1.5
    Filename 'e3mc/k3-j721e-common-proc-board-e3mc.dtb'.
    Load address: 0x88000000                             
    Loading: #T #####################
             20.5 KiB/s                                  
    done                                                 
    Bytes transferred = 107889 (1a571 hex)
    am65_cpsw_nuss_port ethernet@46000000port@1: K3 CPSW: rflow_id_base: 2
    link up on port 1, speed 1000, full duplex
    Using ethernet@46000000port@1 device
    TFTP from server 192.168.1.2; our IP address is 192.168.1.5
    Filename 'e3mc/e3mc.dtbo'.
    Load address: 0x89000000                             
    Loading: #T #                                        
             2 KiB/s                                     
    done                                                 
    Bytes transferred = 10144 (27a0 hex)
    ## Flattened Device Tree blob at 88000000
       Booting using the fdt blob at 0x88000000
       Loading Device Tree to 000000008fee2000, end 000000008fffffff ... OK
    
    Starting kernel ...                                  
    
    [    0.000000] Booting Linux on physical CPU 0x0000000000 [0x411fd080]
    [    0.000000] Linux version 5.10.120-g0e7d11efa2 (oe-user@oe-host) (aarch64-none-linux-gnu-gcc (GNU Toolc2
    [    0.000000] Machine model: Texas Instruments K3 J721E SoC
    [    0.000000] earlycon: ns16550a0 at MMIO32 0x0000000002800000 (options '')
    [    0.000000] printk: bootconsole [ns16550a0] enabled
    [    0.000000] efi: UEFI not found.
    [    0.000000] OF: reserved mem: initialized node main-ic-mpu-mcu20-region@03600000, compatible id dma-heat
    [    0.000000] Reserved memory: created DMA memory pool at 0x00000000a0000000, size 1 MiB
    [    0.000000] OF: reserved mem: initialized node e3mc-r5f-dma-memory@a0000000, compatible id shared-dma-pl
    [    0.000000] Reserved memory: created DMA memory pool at 0x00000000a0100000, size 7 MiB
    [    0.000000] OF: reserved mem: initialized node e3mc-r5f-memory@a0100000, compatible id shared-dma-pool
    [    0.000000] Reserved memory: created DMA memory pool at 0x00000000a0800000, size 1 MiB
    [    0.000000] OF: reserved mem: initialized node e3mc-r5f-dma-memory@a0800000, compatible id shared-dma-pl
    [    0.000000] Reserved memory: created DMA memory pool at 0x00000000a0900000, size 7 MiB
    [    0.000000] OF: reserved mem: initialized node e3mc-r5f-memory@a0900000, compatible id shared-dma-pool
    [    0.000000] Reserved memory: created DMA memory pool at 0x00000000a1000000, size 1 MiB
    [    0.000000] OF: reserved mem: initialized node e3mc-r5f-dma-memory@a1000000, compatible id shared-dma-pl
    [    0.000000] Reserved memory: created DMA memory pool at 0x00000000a1100000, size 7 MiB
    [    0.000000] OF: reserved mem: initialized node e3mc-r5f-memory@a1100000, compatible id shared-dma-pool
    [    0.000000] Reserved memory: created DMA memory pool at 0x00000000a1800000, size 1 MiB
    [    0.000000] OF: reserved mem: initialized node e3mc-r5f-dma-memory@a1800000, compatible id shared-dma-pl
    [    0.000000] Reserved memory: created DMA memory pool at 0x00000000a1900000, size 7 MiB
    [    0.000000] OF: reserved mem: initialized node e3mc-r5f-memory@a1900000, compatible id shared-dma-pool
    [    0.000000] Reserved memory: created DMA memory pool at 0x00000000a2000000, size 1 MiB
    [    0.000000] OF: reserved mem: initialized node e3mc-r5f-dma-memory@a2000000, compatible id shared-dma-pl
    [    0.000000] Reserved memory: created DMA memory pool at 0x00000000a2100000, size 7 MiB
    [    0.000000] OF: reserved mem: initialized node e3mc-r5f-memory@a2100000, compatible id shared-dma-pool
    [    0.000000] Reserved memory: created DMA memory pool at 0x00000000a2800000, size 1 MiB
    [    0.000000] OF: reserved mem: initialized node e3mc-r5f-dma-memory@a2800000, compatible id shared-dma-pl
    [    0.000000] Reserved memory: created DMA memory pool at 0x00000000a2900000, size 7 MiB
    [    0.000000] OF: reserved mem: initialized node e3mc-r5f-memory@a2900000, compatible id shared-dma-pool
    [    0.000000] Reserved memory: created DMA memory pool at 0x00000000a3000000, size 1 MiB
    [    0.000000] OF: reserved mem: initialized node e3mc-c66-dma-memory@a3000000, compatible id shared-dma-pl
    
    Now the linux kernel is happily booting 
             
             
    

    The file "/home/thomas/e3mc_2//lib/firmware/j7-main-r5f0_0-fw" is the dru testapp from previous post (thomas@tda4vmx:~/e3mc_2/lib/firmware$  cp ~/tda4vmx/psdk/pdk_jacinto_08_04_00_21/packages/ti/binary/udma_dru_direct_tr_testapp_freertos/bin/j721e_evm/udma_dru_direct_tr_testapp_freertos_mcu2_0_release.xer5f j7-main-r5f0_0-fw).

    The output from mcu UART (basically from the j7-main-r5f0_0-fw) is following:

    UDMA DRU Direct TR application started...

    Nothing more, so the app crashes when it tries to access the COMPUTE_CLUSTER0_DRU_QUEUE register I guess.

    To test this with CCS, I just replace j7-main-r5f0_0-fw with a kind of "dummyApp". Whereas at the start of the main()-function, the R5 is trapped in a endless loop, to give me time to connect with CCS before the R5 can start its application.

    When I boot up now the TDA4EVM and then connect CCS to mcu2_0, I got also this error message after trying to write on the COMPUTE_CLUSTER0_DRU_QUEUE with the CCS MemoryViewer (MAIN_Cortex_R5_0_0: Trouble Writing Memory Block at 0x6d008000 on Page 0 of Length 0x4: (Error -1065 @ 0x0) Unable to access device memory).

    Can you please check this? How does your test procedure looks in detail?

    Thank you and best regards,
    Thomas

  • Hi Thomas,

    Yes, i used the exact same release. But i flashed SD card using vision apps scripts, booted Linux, connected mcu2_0 and tried to access these registers from mcu2_0 in CCS. I also tried running standard vision_apps firmware on mcu2_0 and then tried to access these registers, there were still accessible.. 

    Are you sure that this example is running fine in CCS boot mode? 

    Also how are you loading this example using uboot? Have you made sure that this example is using the correct carved out memory map for mcu2_0? 

    Regards,

    Brijesh 

  • Hi Thomas,

    Surprisingly, i am not able to write to these registers, as you suggested. But this happens only in the uboot boot flow. If i use SBL, then i am able to write to these registers. I am not sure why this is happening, am checking with the team.

    Regards,

    Brijesh

  • Good morning Brijesh,

    I am able to write here again. Thank you for confirmation that you also experience the issue and for checking it. It is not the only region which is not writeable anymore, but it was the first we experienced. I am looking forward for a solution/workaround.

    Best regards,

    Thomas

  • Hi Thomas,

    Good morning.

    Surprisingly, this region is not firewalled, i dont get firewall exception. But still not able to access from R5F. Still further checking it..

    Regards,

    Brijesh

  • Hi Brijesh,

    any updates on this? I had hoped that this would be some obvius and easy to fix...

    Best regards,
    Thomas

  • Hi Thomas,

    Not yet, still looking at this issue. 

    Regards,

    Brijesh

  • Hi Thomas,

    I dont see firewall exception, no firewall enabled in this region, nothing in the RAT mapping, MPU setting seems to be correct, but still it is not working. Still looking into it.

    Regards,

    Brijesh

  • Hi Brijesh,

    thank you for the quick update.

    Best regards,
    Thomas

  • Hi Brijesh,

    I would kindly ask if there are any updates?

    Best regards,
    Thomas

  • Hi Thomas,

    I have raised this issue with our SDK team, but still dont have any update. Let me check with the team.

    Regards,

    Brijesh

  • Hi Brijesh,

    are there any updates?

    Best regards,
    Thomas

  • Hi Thomas,

    We checked this on SDK8.6, which is going to be available in few weeks, it is working fine. So could you please wait for few weeks and check it on SDK8.6 release?

    Regards,

    Brijesh

  • Hi Brijesh,

    yes of course. If possible could you share some insights about the reasons why some particiular memory areas have not been writeable anymore?
    Just that I get a better sense for the future, when something similar happens again that I know where I can have a look into...

    Thanks and best regards,
    Thomas

  • Hi Thomas,

    The doubt is on below two commit ids on https://git.ti.com/cgit/ti-u-boot/ti-u-boot/log/?h=ti-u-boot-2021.01 branch. But if you could use SDK8.6, it would be better.

    e581756069edbe27ac3a02c2413606a383fd8e0f
    73c3310f45cca9ff1af445d1b5a16cac0a9bad5d

    Regards,

    Brijesh

  • Hi Brijesh,

    my colleague has tested the SDK 8.6 as you suggested, but the error is still the same. Can you please verify this on your side?

    You said 1 month ago, that you checked this and it worked. Can you explain what exactly you checked?

    Thanks and best regards,

    Thomas

  • Hi Thomas,

    Yes, we did check it about a month ago and were able to access DRU registers. Not sure what is changed. Let me check again on SDK8.6 and will get back to you.

    Regards,

    Brijesh

  • Hi Brijesh,

    thank you for looking into it again. Do you have any update?

    Best regards,

    Thomas

  • Hi Thomas,

    Not yet, i have reported it to our development team and will update you as soon as i get some solution. 

    Regards,

    Brijesh

  • Hi Brijesh,

    is there any progress?
    (I also wanted to avoid that this thread gets closed automatically due to inactivity)

    Regards,
    Thomas

  • Thomas,

    Not yet, i have pinged the developer and will update as soon as i get the answer.

    Regards,

    Brijesh

  • Hi Brijesh,

    (avoiding that this thread gets closed automatically due to inactivity)
    are there any news?

    Regards,
    Thomas

  • Hi Thomas,

    Sorry for the late reply. I checked with the team and it is still under debug. Will update this ticket, as soon as i get the update from the team.

    Regards,

    Brijesh

  • Hi Thomas,

    Just to keep this ticket open, we still have not found reason for inaccessibility for DRU registers, we are still actively looking into it. 

    Regards,

    Brijesh

  • Hi Thomas,

    Updating this ticket, based on our conversion.

    I have shared a temporary fix to enable this feature. Please check if this helps.

    Regards,

    Brijesh