Immediate offset problem with the LDR commands

Note that the absolute source for information about ARM instructions is the ARM web site.

And problems can often be seen from multiple angles - and it is often required to see them from more than one angle.

That is a reason why this forum has lots of discussions in the threads. People posts hints and clues to problems to move the debate forward.

If someone do post a link where they have seen a specific quote (such as the limitation for the immediate value), then people may respond back with alternative links showing additional information. In this thread, people did post hints about narrow and wide instructions - the TI document doesn't mention anything about them. The thread also mentioned a couple of terms and references that could have been picked up by Google to fetch more information about the issue.

Chip manufacturers (who buys the core design from ARM) wants to present "for dummies" documents to make it easy for people to get going. Alas, the shoft-form documentation do get people going but doesn't help them when they get stuck. Having a simplified map works well if you drive by GPS, or takes the highway (or program in C). But if you want to take the shortest route (possibly even accepting dirt tracks) then you do need the full information.

A traditional way to handle problems is to make assumptions, and then see if they can be proved or disproved. And if stuck, to post on a forum telling what assumption based on what premisses and then see if people can point at errors in the logic or missing data.

We often can. But we often do dish out details one-by-one instead of going directly to posting complete text sections from different documents. The reason is that a text document may tell "what happens". It seldom discuss "why". And a developer is very much helped by considering the "why".

In this case, people who selects assembler does it because they want control. And having an assembler that is too clever will in some situations get in the way. So while it is very nice with assemblers with good macro functionality, almost all developers wants to keep the right to decide exactly what instructions that gets used. The logical alternative is of course to instead focusing on what problem to solve, and switch to a problem-solving language like C where the task of the compiler is to figure out a reasonably efficient mapping from the C code into processor instructions.

Another reason why people like to debate things on web forums is that we don't know everything. But if we debate things, we will be able to share some of the things we know, while at the same time having the chance of picking up some new knowledge in return. If just posting final solutions we wouldn't evolve ourselves - and since we do post help for free, we somehow needs some potential value in return.

When we do debate, the thread can progress quickly or slowly. When someone always returns to the original post, then the thread will progress very slowly. When the debate can manage to solve small sub-steps of a problem then the discussion can directly progress to looking at new, potential sub-problems or steps needed to reach a good conclusion to the debate.

Note that the absolute source for information about ARM instructions is the ARM web site.

And problems can often be seen from multiple angles - and it is often required to see them from more than one angle.

That is a reason why this forum has lots of discussions in the threads. People posts hints and clues to problems to move the debate forward.

If someone do post a link where they have seen a specific quote (such as the limitation for the immediate value), then people may respond back with alternative links showing additional information. In this thread, people did post hints about narrow and wide instructions - the TI document doesn't mention anything about them. The thread also mentioned a couple of terms and references that could have been picked up by Google to fetch more information about the issue.

Chip manufacturers (who buys the core design from ARM) wants to present "for dummies" documents to make it easy for people to get going. Alas, the shoft-form documentation do get people going but doesn't help them when they get stuck. Having a simplified map works well if you drive by GPS, or takes the highway (or program in C). But if you want to take the shortest route (possibly even accepting dirt tracks) then you do need the full information.

A traditional way to handle problems is to make assumptions, and then see if they can be proved or disproved. And if stuck, to post on a forum telling what assumption based on what premisses and then see if people can point at errors in the logic or missing data.

We often can. But we often do dish out details one-by-one instead of going directly to posting complete text sections from different documents. The reason is that a text document may tell "what happens". It seldom discuss "why". And a developer is very much helped by considering the "why".

In this case, people who selects assembler does it because they want control. And having an assembler that is too clever will in some situations get in the way. So while it is very nice with assemblers with good macro functionality, almost all developers wants to keep the right to decide exactly what instructions that gets used. The logical alternative is of course to instead focusing on what problem to solve, and switch to a problem-solving language like C where the task of the compiler is to figure out a reasonably efficient mapping from the C code into processor instructions.

Another reason why people like to debate things on web forums is that we don't know everything. But if we debate things, we will be able to share some of the things we know, while at the same time having the chance of picking up some new knowledge in return. If just posting final solutions we wouldn't evolve ourselves - and since we do post help for free, we somehow needs some potential value in return.

When we do debate, the thread can progress quickly or slowly. When someone always returns to the original post, then the thread will progress very slowly. When the debate can manage to solve small sub-steps of a problem then the discussion can directly progress to looking at new, potential sub-problems or steps needed to reach a good conclusion to the debate.

Please look to page 3.20 of following document.

infocenter.arm.com/.../DUI0552A_cortex_m3_dgug.pdf

This document wrong same as luminary. Isnt it?

I can not see the 0x00 ... 0x1f offset range for the LDRB command.

I am looking reliable document.

I am looking reliable document.

But that doesn't help if you're so intent on proving your point that you only read those parts of a single document that appear to support it, without looking left and right.

In the case at hand, for starters you're overlooking section 3.3.8 of same document.

I am looking but i dont see.

.N and .W suffix ok but where is writing offset range for the 0x00 ... 0x1f.

infocenter.arm.com/.../QRC0006_UAL16.pdf