Embedded Firmware Question - Memory dump
Ok so the back story is this. I landed an online code interview with a company that shall remain nameless.
I know I am not ready for a job there but I was basically given the chance by an insider. Anyways below is a picture of the question.
I have experience doing register programming and dealing with micro-controllers, but all of this is on my own so I have never seen "real industry up-to-standard code" so to speak. I most definitely have never dealt with any "memory dump" from a micro-controller , because well I have never had such bug or even knew it could do that...
My question is two fold.. first is the questions in the picture... if anyone can answer them.... and my other question is...if a micro-controller fails or something goes wrong and it stops working then how does it do a memory dump? seems to me that it would require it to be in working order to execute something like that. otherwise youll just get the memory dump of what things looked like "before" the crash.
microcontroller embedded memory firmware dump
add a comment |
Ok so the back story is this. I landed an online code interview with a company that shall remain nameless.
I know I am not ready for a job there but I was basically given the chance by an insider. Anyways below is a picture of the question.
I have experience doing register programming and dealing with micro-controllers, but all of this is on my own so I have never seen "real industry up-to-standard code" so to speak. I most definitely have never dealt with any "memory dump" from a micro-controller , because well I have never had such bug or even knew it could do that...
My question is two fold.. first is the questions in the picture... if anyone can answer them.... and my other question is...if a micro-controller fails or something goes wrong and it stops working then how does it do a memory dump? seems to me that it would require it to be in working order to execute something like that. otherwise youll just get the memory dump of what things looked like "before" the crash.
microcontroller embedded memory firmware dump
add a comment |
Ok so the back story is this. I landed an online code interview with a company that shall remain nameless.
I know I am not ready for a job there but I was basically given the chance by an insider. Anyways below is a picture of the question.
I have experience doing register programming and dealing with micro-controllers, but all of this is on my own so I have never seen "real industry up-to-standard code" so to speak. I most definitely have never dealt with any "memory dump" from a micro-controller , because well I have never had such bug or even knew it could do that...
My question is two fold.. first is the questions in the picture... if anyone can answer them.... and my other question is...if a micro-controller fails or something goes wrong and it stops working then how does it do a memory dump? seems to me that it would require it to be in working order to execute something like that. otherwise youll just get the memory dump of what things looked like "before" the crash.
microcontroller embedded memory firmware dump
Ok so the back story is this. I landed an online code interview with a company that shall remain nameless.
I know I am not ready for a job there but I was basically given the chance by an insider. Anyways below is a picture of the question.
I have experience doing register programming and dealing with micro-controllers, but all of this is on my own so I have never seen "real industry up-to-standard code" so to speak. I most definitely have never dealt with any "memory dump" from a micro-controller , because well I have never had such bug or even knew it could do that...
My question is two fold.. first is the questions in the picture... if anyone can answer them.... and my other question is...if a micro-controller fails or something goes wrong and it stops working then how does it do a memory dump? seems to me that it would require it to be in working order to execute something like that. otherwise youll just get the memory dump of what things looked like "before" the crash.
microcontroller embedded memory firmware dump
microcontroller embedded memory firmware dump
asked Dec 1 at 5:40
Edwin Fairchild
35218
35218
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
The memory dump in question was not taken at crash. It was taken for debuging. A memory dump 'at crash' is created for a software error (exeption) detected at runtime by the program or debugger.
The question is simple. The 'dump' contains a memory occupied by an instance of the struct packet_S. You need only interpret the bytes into data types of member variables. And the struct is very simple. It takes 1 + 2*2 + 4 bytes.
The content of the struct starts at 0x1010 so count
is 0x6F. This is not affected by 'endianes'. The ints and the long are affected by byte ordering, so you need to interpret them for A and B.
so that means data[0] and [1] would be 0xD5 and 0x70 ?
– Edwin Fairchild
Dec 1 at 6:14
1
no, int is two bytes
– Juraj
Dec 1 at 6:15
oh no because data is uint16 so data[0] would be 0xD570 ? correct?
– Edwin Fairchild
Dec 1 at 6:16
1
it depends if end byte is first or last (endian)
– Juraj
Dec 1 at 6:16
3
This is not quite correct. Without structure packing, the compiler will align everything to 4 byte boundaries. The structure uses 4 * 4 bytes.
– Jon
Dec 1 at 10:01
|
show 5 more comments
This is a bit of a trick question. Without structure packing each element will be aligned to a 4 byte boundary. This means there are quite a few padding bytes in the structure. Even though these are not zero, their value is irrelevant. Also note that the compiler cannot reorder the elements in the struct. This information means the structure's memory layout is well defined.
Little endian means the lowest address is the least significant byte. So we can calculate the structure values as follows:
count = 0x6f
data[0] = 0x9994
data[1] = 0xb2ca
timestamp = 0x2ec5b98e
In some version of compiler, the structure "uint16_t data[2]" is packed into two 16 bit data. because some controller has an ALU feature that they can work with int16 in the pipeline.
– M KS
Dec 1 at 10:47
now you solved it for him and he for sure don't get the job, if the potential employer finds this
– Juraj
Dec 1 at 11:00
@Juraj oh no the interview is over, they record your keystroke and once you close the window it’s over no second chances lol
– Edwin Fairchild
Dec 1 at 21:01
add a comment |
if a micro-controller fails or something goes wrong and it stops working then how does it do a memory dump?
It generally doesn't. Doing a broad memory dump of all of RAM is risky, because under many microcontroller architectures, doing a read from certain SFR addresses has unintended effects, so you can't naively iterate through indirect addressing over all of the RAM address space.
If this is something you really, really need, one option is to rig up a 1980s-style microcontroller with an external memory bus and a watchdog. If the watchdog times out, have a secondary post-mortem microcontroller that saves the RAM contents to an EEPROM chip (or whatever).
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
return StackExchange.using("mathjaxEditing", function () {
StackExchange.MarkdownEditor.creationCallbacks.add(function (editor, postfix) {
StackExchange.mathjaxEditing.prepareWmdForMathJax(editor, postfix, [["\$", "\$"]]);
});
});
}, "mathjax-editing");
StackExchange.ifUsing("editor", function () {
return StackExchange.using("schematics", function () {
StackExchange.schematics.init();
});
}, "cicuitlab");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "135"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: false,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: null,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f409863%2fembedded-firmware-question-memory-dump%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
The memory dump in question was not taken at crash. It was taken for debuging. A memory dump 'at crash' is created for a software error (exeption) detected at runtime by the program or debugger.
The question is simple. The 'dump' contains a memory occupied by an instance of the struct packet_S. You need only interpret the bytes into data types of member variables. And the struct is very simple. It takes 1 + 2*2 + 4 bytes.
The content of the struct starts at 0x1010 so count
is 0x6F. This is not affected by 'endianes'. The ints and the long are affected by byte ordering, so you need to interpret them for A and B.
so that means data[0] and [1] would be 0xD5 and 0x70 ?
– Edwin Fairchild
Dec 1 at 6:14
1
no, int is two bytes
– Juraj
Dec 1 at 6:15
oh no because data is uint16 so data[0] would be 0xD570 ? correct?
– Edwin Fairchild
Dec 1 at 6:16
1
it depends if end byte is first or last (endian)
– Juraj
Dec 1 at 6:16
3
This is not quite correct. Without structure packing, the compiler will align everything to 4 byte boundaries. The structure uses 4 * 4 bytes.
– Jon
Dec 1 at 10:01
|
show 5 more comments
The memory dump in question was not taken at crash. It was taken for debuging. A memory dump 'at crash' is created for a software error (exeption) detected at runtime by the program or debugger.
The question is simple. The 'dump' contains a memory occupied by an instance of the struct packet_S. You need only interpret the bytes into data types of member variables. And the struct is very simple. It takes 1 + 2*2 + 4 bytes.
The content of the struct starts at 0x1010 so count
is 0x6F. This is not affected by 'endianes'. The ints and the long are affected by byte ordering, so you need to interpret them for A and B.
so that means data[0] and [1] would be 0xD5 and 0x70 ?
– Edwin Fairchild
Dec 1 at 6:14
1
no, int is two bytes
– Juraj
Dec 1 at 6:15
oh no because data is uint16 so data[0] would be 0xD570 ? correct?
– Edwin Fairchild
Dec 1 at 6:16
1
it depends if end byte is first or last (endian)
– Juraj
Dec 1 at 6:16
3
This is not quite correct. Without structure packing, the compiler will align everything to 4 byte boundaries. The structure uses 4 * 4 bytes.
– Jon
Dec 1 at 10:01
|
show 5 more comments
The memory dump in question was not taken at crash. It was taken for debuging. A memory dump 'at crash' is created for a software error (exeption) detected at runtime by the program or debugger.
The question is simple. The 'dump' contains a memory occupied by an instance of the struct packet_S. You need only interpret the bytes into data types of member variables. And the struct is very simple. It takes 1 + 2*2 + 4 bytes.
The content of the struct starts at 0x1010 so count
is 0x6F. This is not affected by 'endianes'. The ints and the long are affected by byte ordering, so you need to interpret them for A and B.
The memory dump in question was not taken at crash. It was taken for debuging. A memory dump 'at crash' is created for a software error (exeption) detected at runtime by the program or debugger.
The question is simple. The 'dump' contains a memory occupied by an instance of the struct packet_S. You need only interpret the bytes into data types of member variables. And the struct is very simple. It takes 1 + 2*2 + 4 bytes.
The content of the struct starts at 0x1010 so count
is 0x6F. This is not affected by 'endianes'. The ints and the long are affected by byte ordering, so you need to interpret them for A and B.
edited Dec 1 at 11:00
answered Dec 1 at 6:05
Juraj
17415
17415
so that means data[0] and [1] would be 0xD5 and 0x70 ?
– Edwin Fairchild
Dec 1 at 6:14
1
no, int is two bytes
– Juraj
Dec 1 at 6:15
oh no because data is uint16 so data[0] would be 0xD570 ? correct?
– Edwin Fairchild
Dec 1 at 6:16
1
it depends if end byte is first or last (endian)
– Juraj
Dec 1 at 6:16
3
This is not quite correct. Without structure packing, the compiler will align everything to 4 byte boundaries. The structure uses 4 * 4 bytes.
– Jon
Dec 1 at 10:01
|
show 5 more comments
so that means data[0] and [1] would be 0xD5 and 0x70 ?
– Edwin Fairchild
Dec 1 at 6:14
1
no, int is two bytes
– Juraj
Dec 1 at 6:15
oh no because data is uint16 so data[0] would be 0xD570 ? correct?
– Edwin Fairchild
Dec 1 at 6:16
1
it depends if end byte is first or last (endian)
– Juraj
Dec 1 at 6:16
3
This is not quite correct. Without structure packing, the compiler will align everything to 4 byte boundaries. The structure uses 4 * 4 bytes.
– Jon
Dec 1 at 10:01
so that means data[0] and [1] would be 0xD5 and 0x70 ?
– Edwin Fairchild
Dec 1 at 6:14
so that means data[0] and [1] would be 0xD5 and 0x70 ?
– Edwin Fairchild
Dec 1 at 6:14
1
1
no, int is two bytes
– Juraj
Dec 1 at 6:15
no, int is two bytes
– Juraj
Dec 1 at 6:15
oh no because data is uint16 so data[0] would be 0xD570 ? correct?
– Edwin Fairchild
Dec 1 at 6:16
oh no because data is uint16 so data[0] would be 0xD570 ? correct?
– Edwin Fairchild
Dec 1 at 6:16
1
1
it depends if end byte is first or last (endian)
– Juraj
Dec 1 at 6:16
it depends if end byte is first or last (endian)
– Juraj
Dec 1 at 6:16
3
3
This is not quite correct. Without structure packing, the compiler will align everything to 4 byte boundaries. The structure uses 4 * 4 bytes.
– Jon
Dec 1 at 10:01
This is not quite correct. Without structure packing, the compiler will align everything to 4 byte boundaries. The structure uses 4 * 4 bytes.
– Jon
Dec 1 at 10:01
|
show 5 more comments
This is a bit of a trick question. Without structure packing each element will be aligned to a 4 byte boundary. This means there are quite a few padding bytes in the structure. Even though these are not zero, their value is irrelevant. Also note that the compiler cannot reorder the elements in the struct. This information means the structure's memory layout is well defined.
Little endian means the lowest address is the least significant byte. So we can calculate the structure values as follows:
count = 0x6f
data[0] = 0x9994
data[1] = 0xb2ca
timestamp = 0x2ec5b98e
In some version of compiler, the structure "uint16_t data[2]" is packed into two 16 bit data. because some controller has an ALU feature that they can work with int16 in the pipeline.
– M KS
Dec 1 at 10:47
now you solved it for him and he for sure don't get the job, if the potential employer finds this
– Juraj
Dec 1 at 11:00
@Juraj oh no the interview is over, they record your keystroke and once you close the window it’s over no second chances lol
– Edwin Fairchild
Dec 1 at 21:01
add a comment |
This is a bit of a trick question. Without structure packing each element will be aligned to a 4 byte boundary. This means there are quite a few padding bytes in the structure. Even though these are not zero, their value is irrelevant. Also note that the compiler cannot reorder the elements in the struct. This information means the structure's memory layout is well defined.
Little endian means the lowest address is the least significant byte. So we can calculate the structure values as follows:
count = 0x6f
data[0] = 0x9994
data[1] = 0xb2ca
timestamp = 0x2ec5b98e
In some version of compiler, the structure "uint16_t data[2]" is packed into two 16 bit data. because some controller has an ALU feature that they can work with int16 in the pipeline.
– M KS
Dec 1 at 10:47
now you solved it for him and he for sure don't get the job, if the potential employer finds this
– Juraj
Dec 1 at 11:00
@Juraj oh no the interview is over, they record your keystroke and once you close the window it’s over no second chances lol
– Edwin Fairchild
Dec 1 at 21:01
add a comment |
This is a bit of a trick question. Without structure packing each element will be aligned to a 4 byte boundary. This means there are quite a few padding bytes in the structure. Even though these are not zero, their value is irrelevant. Also note that the compiler cannot reorder the elements in the struct. This information means the structure's memory layout is well defined.
Little endian means the lowest address is the least significant byte. So we can calculate the structure values as follows:
count = 0x6f
data[0] = 0x9994
data[1] = 0xb2ca
timestamp = 0x2ec5b98e
This is a bit of a trick question. Without structure packing each element will be aligned to a 4 byte boundary. This means there are quite a few padding bytes in the structure. Even though these are not zero, their value is irrelevant. Also note that the compiler cannot reorder the elements in the struct. This information means the structure's memory layout is well defined.
Little endian means the lowest address is the least significant byte. So we can calculate the structure values as follows:
count = 0x6f
data[0] = 0x9994
data[1] = 0xb2ca
timestamp = 0x2ec5b98e
answered Dec 1 at 9:58
Jon
3,213714
3,213714
In some version of compiler, the structure "uint16_t data[2]" is packed into two 16 bit data. because some controller has an ALU feature that they can work with int16 in the pipeline.
– M KS
Dec 1 at 10:47
now you solved it for him and he for sure don't get the job, if the potential employer finds this
– Juraj
Dec 1 at 11:00
@Juraj oh no the interview is over, they record your keystroke and once you close the window it’s over no second chances lol
– Edwin Fairchild
Dec 1 at 21:01
add a comment |
In some version of compiler, the structure "uint16_t data[2]" is packed into two 16 bit data. because some controller has an ALU feature that they can work with int16 in the pipeline.
– M KS
Dec 1 at 10:47
now you solved it for him and he for sure don't get the job, if the potential employer finds this
– Juraj
Dec 1 at 11:00
@Juraj oh no the interview is over, they record your keystroke and once you close the window it’s over no second chances lol
– Edwin Fairchild
Dec 1 at 21:01
In some version of compiler, the structure "uint16_t data[2]" is packed into two 16 bit data. because some controller has an ALU feature that they can work with int16 in the pipeline.
– M KS
Dec 1 at 10:47
In some version of compiler, the structure "uint16_t data[2]" is packed into two 16 bit data. because some controller has an ALU feature that they can work with int16 in the pipeline.
– M KS
Dec 1 at 10:47
now you solved it for him and he for sure don't get the job, if the potential employer finds this
– Juraj
Dec 1 at 11:00
now you solved it for him and he for sure don't get the job, if the potential employer finds this
– Juraj
Dec 1 at 11:00
@Juraj oh no the interview is over, they record your keystroke and once you close the window it’s over no second chances lol
– Edwin Fairchild
Dec 1 at 21:01
@Juraj oh no the interview is over, they record your keystroke and once you close the window it’s over no second chances lol
– Edwin Fairchild
Dec 1 at 21:01
add a comment |
if a micro-controller fails or something goes wrong and it stops working then how does it do a memory dump?
It generally doesn't. Doing a broad memory dump of all of RAM is risky, because under many microcontroller architectures, doing a read from certain SFR addresses has unintended effects, so you can't naively iterate through indirect addressing over all of the RAM address space.
If this is something you really, really need, one option is to rig up a 1980s-style microcontroller with an external memory bus and a watchdog. If the watchdog times out, have a secondary post-mortem microcontroller that saves the RAM contents to an EEPROM chip (or whatever).
add a comment |
if a micro-controller fails or something goes wrong and it stops working then how does it do a memory dump?
It generally doesn't. Doing a broad memory dump of all of RAM is risky, because under many microcontroller architectures, doing a read from certain SFR addresses has unintended effects, so you can't naively iterate through indirect addressing over all of the RAM address space.
If this is something you really, really need, one option is to rig up a 1980s-style microcontroller with an external memory bus and a watchdog. If the watchdog times out, have a secondary post-mortem microcontroller that saves the RAM contents to an EEPROM chip (or whatever).
add a comment |
if a micro-controller fails or something goes wrong and it stops working then how does it do a memory dump?
It generally doesn't. Doing a broad memory dump of all of RAM is risky, because under many microcontroller architectures, doing a read from certain SFR addresses has unintended effects, so you can't naively iterate through indirect addressing over all of the RAM address space.
If this is something you really, really need, one option is to rig up a 1980s-style microcontroller with an external memory bus and a watchdog. If the watchdog times out, have a secondary post-mortem microcontroller that saves the RAM contents to an EEPROM chip (or whatever).
if a micro-controller fails or something goes wrong and it stops working then how does it do a memory dump?
It generally doesn't. Doing a broad memory dump of all of RAM is risky, because under many microcontroller architectures, doing a read from certain SFR addresses has unintended effects, so you can't naively iterate through indirect addressing over all of the RAM address space.
If this is something you really, really need, one option is to rig up a 1980s-style microcontroller with an external memory bus and a watchdog. If the watchdog times out, have a secondary post-mortem microcontroller that saves the RAM contents to an EEPROM chip (or whatever).
answered Dec 1 at 5:45
Reinderien
862413
862413
add a comment |
add a comment |
Thanks for contributing an answer to Electrical Engineering Stack Exchange!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
Use MathJax to format equations. MathJax reference.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2felectronics.stackexchange.com%2fquestions%2f409863%2fembedded-firmware-question-memory-dump%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown