I’ve confirmed that both the Python and the mbed code produce the same result after the first SHA512 update operation. So there’s something about the way I’m doing the second update in the mbed code that needs correction.
I was able to solve my problem. My workaround in the code block below shows that cloning my context before the call to finish_ret() and using the cloned context for the second update_ret() solves my issue. Restated, the call to finish_ret() modifies context preventing further updates from being valid. I recommend this behavior be explained in the API docs.
// Perform SHA512 hash twice on the public key
mbedtls_sha512_init(&sha_ctx);
mbedtls_sha512_starts_ret(&sha_ctx, 0);
mbedtls_sha512_update_ret(&sha_ctx, pub_key, SECP384R1_KEY_SZ); // once
mbedtls_sha512_clone(&sha_ctx2, &sha_ctx);
mbedtls_sha512_finish_ret(&sha_ctx, hash);
mbedtls_sha512_update_ret(&sha_ctx2, hash, HASH_SZ); // twice
mbedtls_sha512_finish_ret(&sha_ctx2, hash);
mbedtls_sha512_free(&sha_ctx);
mbedtls_sha512_free(&sha_ctx2);