Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Powering down the DP when disabling DAPLink SWD control. #189

Open
wants to merge 1 commit into
base: main
Choose a base branch
from

Conversation

flit
Copy link
Collaborator

@flit flit commented Nov 18, 2016

This patch fixes an issue where target devices were unable to enter the Very Low Power Stop (VLPS) mode when running Kinetis SDK low power demos (and presumably customer apps) when using DAPLink. The J-Link app for OpenSDA does not exhibit the same issue. Note that removing the line in prerun_target_config() that reads the target UUID will also fix the issue.

Issue description from Michal Jakabovic:
Reading from the memory through the SWD causes the debug access port to lock up.

void prerun_target_config(void)
{
    // SIM peripheral   0x40047000
    // address offset   0x    1054
    uint32_t UUID_LOC = 0x40048054;
    uint32_t uuid[4] = {0};
    // get a hold of the target
    target_set_state(RESET_PROGRAM);
    // do mass-erase if necessary
    target_unlock_sequence();
    // get target UUID
    swd_read_memory(UUID_LOC, (uint8_t *)&uuid, 16);
    // stringify and store the MAC generated from a UUID
    info_set_uuid_target(uuid);
    // Let the target run
    target_set_state(RESET_RUN);
}

The function above is located in the /source/target/target_reset_Kseries.c file. This function calls the function swd_read_block() of the /source/daplink/interface/swd_host.c file from the swd_read_memory(). On the last read of the UUID from memory in the loop of the following image the debug access port, DP, sets its flagbit of the CTRL/STAT register STICKYERR to 1, which prevents any future communication with this register.

    // dummy read
    if (swd_transfer_retry(req, (uint32_t *)data) != 0x01) {
        return 0;
    }

    for (i = 0; i < size_in_words; i++) {
        if (swd_transfer_retry(req, (uint32_t *)data) != 0x01) {
            return 0;
        }

        data += 4;
    }

    // dummy read
    req = SWD_REG_DP | SWD_REG_R | SWD_REG_ADR(DP_RDBUFF);
    ack = swd_transfer_retry(req, NULL);
    return (ack == 0x01);

This issue has occurred on all boards I have tested it on, including TWR-KE18F, FRDM-K64F, FRDM-KL46Z, as soon as the board is powered up.

To recover from this error it is required to set the STKERRCLR bit of the DP_ABORT register and send a reset request to the control/stat register.

@c1728p9
Copy link
Contributor

c1728p9 commented Nov 18, 2016

This issue should already be fixed by #175. Can you confirm?

@c1728p9
Copy link
Contributor

c1728p9 commented Nov 20, 2016

@flit, looking at this more thoroughly, it might need to be applied on top of #175. Why does the last read of the UUID cause a stickyerr? Also, why is it not sufficient to clear the stickyerr? Is this because of the lockup mentioned? Also, should a similar recovery method be added to pyOCD?

@flit
Copy link
Collaborator Author

flit commented Nov 22, 2016

@c1728p9 Unfortunately I don't have many answers since Michal Jakabovic did all the work on this patch. However, I'm following up with the design team about why the last read of the UUID causes an error. I was also wondering why clearing the stickyerr is not sufficient—I'll try to get an answer.

return 0;
}
}

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

swd_off is just for shutting off the pins. This logic should be added to swd_uninit_debug().

@flit
Copy link
Collaborator Author

flit commented Nov 25, 2016

@c1728p9 Michal did some more testing and writing a 0 to CTRL/STAT then doing a readback works instead of setting CDBGRSTREQ. I'll update the patch. (And I'm trying to figure out why the readback is required.)

@c1728p9
Copy link
Contributor

c1728p9 commented Nov 30, 2016

@flit, let me know what you find and when this patch is ready to start testing.

@c1728p9
Copy link
Contributor

c1728p9 commented Dec 29, 2016

any updates on this @flit?

Copy link
Contributor

@c1728p9 c1728p9 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Needs updating and rebasing

@0xc0170
Copy link
Contributor

0xc0170 commented Nov 8, 2019

@flit Shall we rebase and update this one?

@mathias-arm
Copy link
Collaborator

@flit based on #853, I think this PR should be changed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants