ryan.vansickle_rm5 | 16 Apr 18:57 2014
Picon

issues running builtin apps

Our company is trying to use nuttx on a project, and I am working on getting up to speed with all things nuttx. The target platform at the moment is the stm32f4discovery board and then we plan to port onto a new custom board that used the discovery reference design as the basis.  I have successfully built nuttx for the discovery platform using the linux native arm toolchain, the buildroot toolchain, and codesourcery all on a Linux host so far so good.  
The target configuration I started with was the usbnsh set of configs and now I am at the point of adding more drivers and example apps to the build so that I can demo the nuttx capabilities to management and our customer.  One of the current problems I am running into is not being able to run the example apps.  I am guessing I am missing something simple, but I haven't yet found Documentation or forum conversations that have helped me fix the issue.
The issue is I have apps built and they are showing up when I type help, but when I try to execute nsh says it can't find the app.  See below:

nsh> help
help usage:  help [-v] [<cmd>]

  [           dd          help        mkfatfs     ps          test        
  ?           df          hexdump     mkfifo      pwd       &nbsp ; true        
  break       echo        kill        mkrd        rm          umount      
  cat         exec        losetup     mh          rmdir       unset       
  cd          exit        ls          mount       set         usleep      
  cp          false       mb          mv          sh          xd          
  cmp         free        mkdir       mw          sleep       

Builtin Apps:
  hello
  json
  ramtest
  sdcard
  sercon
  serdis
  sysinfo
  vi
nsh> hello
nsh: hello: command not found



__._,_.___


__,_._,___
dlsitzer | 16 Apr 18:13 2014
Picon

STM32F2 SPI2 pinmap

Hi Greg,

I think I found a "bug" in arch/arm/src/stm32/chip/stm32f20xxx_pinmap.h.

The GPIO port for GPIO_SPI2_MOSI_1 in line 431 is PORTC when it should be PORTB.

I checked the settings for all GPIO_SPI2_* pins and they match the description from the "Alternate function mapping" table from the datasheet for the F20x series.

BTW: I did not forget my socket patch but need to fix my own bugs : (


__._,_.___


__,_._,___
max.kriegleder | 15 Apr 23:27 2014
Picon

I2C error on STM32F103 [2 Attachments]

Hi Greg,

We have encountered following issue with the I2C driver of the STM32 family (NuttX 6.33). We are using a STMF103 chip and the goal is to read one byte from some device on the I2C1 bus.

The following minimal example shows how we use the driver:

// initialize i2c device
struct i2c_dev_s *dev;
struct i2c_msg_s msg[2];
dev = up_i2cinitialize(1);
I2C_SETFREQUENCY(dev, 400000);

// allocate buffers
const uint8_t read_length = 1;
uint8_t read_register = 0x00;
uint8_t data[read_length] = { 0 };

// setup message
msg[0].addr = 0x01;
msg[0].flags = 0;
msg[0].buffer = &read_register;
msg[0].length = 1;

msg[1].addr = 0x01;
msg[1].flags = I2C_M_READ;
msg[1].buffer = data;
msg[1].length = read_ length;

// transmit
int ret = I2C_TRANSFER(dev, msg, 2);

When we tried this we observed that the logic NAKs after receiving the byte, but instead of immediately sending a STOP it NAKS three more bytes (see attachement: motor_controller_error.png). This specific device was tolerant to this strange behavior, however we have an IMU (MPU6050), which blocks the bus when it doesn't receive the STOP after the first NAK.

We examined this issue and found that there is no simple solution to this problem , but the logic in the I2C ISR seems to have some flaws. This issue may be related to the STM32F103 only, because I tested this with a PX4 (STM32F4) and there the ISR sets the STOP correctly (no additional NAKs after the first one).

My colleague has rewritten the ISR and we now get the desired behavior (see attachment: motor_controller_noerror.png). I also did a quick test on the PX4 and it seems to work fine. We would be happy to contribute our solution, but I guess it needs some proper testing from a third party.

How do you suggest we should proceed?

Thanks,
Max

__._,_.___

Attachment(s) from max.kriegleder-/E1597aS9LQAvxtiuMwx3w@public.gmane.org | View attachments on the web

2 of 2 Photo(s)


__,_._,___
max.kriegleder | 15 Apr 23:26 2014
Picon

I2C error on STM32F103

Hi Greg,

We have encountered following issue with the I2C driver of the STM32 family (NuttX 6.33). We are using a STMF103 chip and the goal is to read one byte from some device on the I2C1 bus.

The following minimal example shows how we use the driver:

// initialize i2c device
struct i2c_dev_s *dev;
struct i2c_msg_s msg[2];
dev = up_i2cinitialize(1);
I2C_SETFREQUENCY(dev, 400000);

// allocate buffers
const uint8_t read_length = 1;
uint8_t read_register = 0x00;
uint8_t data[read_length] = { 0 };

// setup message
msg[0].addr = 0x01;
msg[0].flags = 0;
msg[0].buffer = &read_register;
msg[0] .length = 1;

msg[1].addr = 0x01;
msg[1].flags = I2C_M_READ;
msg[1].buffer = data;
msg[1].length = read_length;

// transmit
int ret = I2C_TRANSFER(dev, msg, 2);

When we tried this we observed that the logic NAKs after receiving the byte, but instead of immediately sending a STOP it NAKS three more bytes (see attachement: motor_controller_error.png). This specific device was tolerant to this strange behavior, however we have an IMU (MPU6050), which blocks the bus when it doesn't receive the STOP after the first NAK.

We examined this issue and found that there is no simple solution to this problem , but the logic in the I2C ISR seems to have some flaws. This issue may be related to the STM32F103 only, because I tested this with a PX4 (STM32F4) and there the ISR sets the STOP correctly (no additional NAKs after the first one).

My colleague has rewritten the ISR and we now get the desired behavior (see attachment: motor_controller_noerror.png). I also did a quick test on the PX4 and it seems to work fine. We would be happy to contribute our solution, but I guess it needs some proper testing from a third party.

How do you suggest we should proceed?

Thanks,
Max

__._,_.___


__,_._,___
max.kriegleder | 15 Apr 23:23 2014
Picon

I2C on STM32F103 [2 Attachments]

Hi Greg,

We have encountered following issue with the I2C driver of the STM32 family (NuttX 6.33). We are using a STMF103 chip and the goal is to read one byte from some device on the I2C1 bus.

The following minimal example shows how we use the driver:

// initialize i2c device
struct i2c_dev_s *dev;
struct i2c_msg_s msg[2];
dev = up_i2cinitialize(1);
I2C_SETFREQUENCY(dev, 400000);

// allocate buffers
const uint8_t read_length = 1;
uint8_t read_register = 0x75;
uint8_t data[read_length] = { 0 };

// setup message
msg[0].addr = 0x68;
msg[0].flags = 0;
msg[0].buffer = &read_register;
msg[0].length = 1;

msg[1].addr = 0x68;
msg[1].flags = I2C_M_READ;
msg[1].buffer = data;
msg[1].length = read_length;

// transmit
int ret = I2C_TRANSFER(dev, msg, 2);

When we tried this we observed that the logic NAKs after receiving the byte, but instead of immediately sending a STOP it NAKS three more bytes (see attachement: motor_controller_error.png). This specific device was tolerant to this strange behavior, however we have an IMU (MPU6050), which blocks the bus when it doesn't receive the STOP after the first NAK.

We examined this issue and found that there is no simple solution to this problem , but the logic in the I2C ISR seems to have some flaws. This issue may be related to the STM32F103 only, because I tested this with a PX4 (STM32F4) and there the ISR sets the STOP correctly (no additional NAKs after the first one).
My colleague has rewritten the ISR and we now get the desired behavior (see attachment: motor_controller_noerror.png). I also did a quick test on the PX4 and it seems to work fine. We would be happy to contribute our solution, but I guess it needs some proper testing from a third party.

How do you suggest we should proceed?

Thanks,
Max


__._,_.___

Attachment(s) from max.kriegleder-/E1597aS9LQAvxtiuMwx3w@public.gmane.org | View attachments on the web

2 of 2 Photo(s)


__,_._,___
Jacques Pelletier | 15 Apr 11:21 2014
Picon

Re: mbed with nsh [1 Attachment]

<*>[Attachment(s) from Jacques Pelletier included below]

I finally made it work with the .config file (see attached file). The 
file was generated with make menuconfig.

I modified the setenv.sh file to poit to my installation of Code 
Sourcery G++ Lite.

The serial UART0 is connected to the PC via a USB to serial converter. 
On Linux, the serial port is /dev/ttyACM0 at 115200 bauds.

On the terminal, the mbed output is:
NuttShell (NSH)
nsh>

JP

<*>Attachment(s) from Jacques Pelletier:

<*> 1 of 1 File(s)
https://groups.yahoo.com/neo/groups/nuttx/attachments/1537904903;_ylc=X3oDMTJyN3M4b2c1BF9TAzk3MzU5NzE0BGdycElkAzIzMzg5MDcwBGdycHNwSWQDMTcwNTAwNjU1OQRzZWMDYXR0YWNobWVudARzbGsDdmlld09uV2ViBHN0aW1lAzEzOTc1NTM2Nzc- 
  <*> .config

------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/nuttx/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/nuttx/join
    (Yahoo! ID required)

<*> To change settings via email:
    nuttx-digest@... 
    nuttx-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    nuttx-unsubscribe@...

<*> Your use of Yahoo Groups is subject to:
    https://info.yahoo.com/legal/us/yahoo/utos/terms/

bdoiron74 | 14 Apr 22:03 2014
Picon

Sam4s Hardfaults! [2 Attachments]

<*>[Attachment(s) from bdoiron74@... included below]

I have been working away at getting nuttx running on a Sam4S Explained-Pro board and I keep getting
hardfaults when I start any significant serial port traffic.  

I'm building using the buildroot tools under cygwin/win7. I've attached my .config file as well as the
verbose build output. 

The simplest test that crashes the system is below. I'm deliberately not using the outer 3rds of the
allocated buffer just in case there was some sort of overrun happening. 

#define CHUNK 256
int serialrx_main(int argc, char *argv[])
{
	char *buf = (char *)malloc(CHUNK*3);
	FILE *f;

	printf("Reading from %s\n", argv[1]);
	f = fopen(argv[1], "r");

	while(1)
	{
		fread(&buf[CHUNK], CHUNK, 1, f);   
		printf("-");
	}

	free(buf);

  return 0;
}

I then feed the RX line from a python script that simply writes characters in a loop. If I send characters
continuously, nuttx crashes _very_ quickly. You'll notice that sometimes that stack pointer is way out
of bounds - I've tried a 32K idle stack, and it crashes the same way. 

/// example output 

nsh> serialrx /dev/ttyS2 &
serialrx [3:100]
nsh> Reading from /dev/ttyS2
------------------------up_hardfault: Hard Fault:
up_hardfault:   IRQ: 3 regs: 20004848
up_hardfault:   BASEPRI: 00000010 PRIMASK: 00000001 IPSR: 00000003 CONTROL: 00000000
up_hardfault:   CFAULTS: 00020000 HFAULTS: 40000000 DFAULTS: 00000008 BFAULTADDR: e000ed38 AFAULTS: 00000000
up_hardfault:   R0: 20003640 20001188 00000000 00000010 00000000 00000002 20003640 20003640
up_hardfault:   R8: 00000006 00000000 00000010 00000000 00009386 20004890 0040e7a1 200036b8
up_hardfault:   xPSR: 40000000 BASEPRI: 00000010 (saved)
up_hardfault: PANIC!!! Hard fault: 40000000
Assertion failed at file:armv7-m/up_hardfault.c line: 184 task: Idle Task
sp:         200047e0
stack base: 200026a8
stack size: 00001000
stack used: 00000000
ERROR: Stack pointer is not within the allocated stack
R0: 20003640 20001188 00000000 00000010 00000000 00000002 20003640 20003640
R8: 00000006 00000000 00000010 00000000 00009386 20004890 0040e7a1 200036b8
xPSR: 40000000 BASEPRI: 00000010 CONTROL: 00000000

///////// and another /////////

nsh> serialrx /dev/ttyS2 &
serialrx [3:100]
nsh> Reading from
/dev/ttyS2
------------------------------------------------------------------------------------------------------------------------------up_hardfault:
Hard Fault:
up_hardfault:   IRQ: 3 regs: 20004860
up_hardfault:   BASEPRI: 00000010 PRIMASK: 00000001 IPSR: 00000003 CONTROL: 00000000
up_hardfault:   CFAULTS: 00000100 HFAULTS: 40000000 DFAULTS: 00000008 BFAULTADDR: e000ed38 AFAULTS: 00000000
up_hardfault:   R0: 00000002 200036b8 2000088c 00000000 2000088c 00000000 00009386 01000000
up_hardfault:   R8: 00403de4 00000000 00000010 00000000 00009386 200048a8 01000000 01000000
up_hardfault:   xPSR: 00000000 BASEPRI: 00000010 (saved)
up_hardfault: PANIC!!! Hard fault: 40000000
Assertion failed at file:armv7-m/up_hardfault.c line: 184 task: work
sp:         200047f8
stack base: 20004928
stack size: 00000ffc
stack used: 000001f8
200047e0: deadbeef 00400bc7 004118b1 000001f8 deadbeef 20004734 004118b1 000001f8
20004800: 00000000 00400e21 004118b1 000001f8 00000000 00400e21 00000010 00000000
20004820: 00009386 200048a8 01000000 01000000 2000115c 20004860 00000003 0040214b
20004840: 400e1200 004003f5 00000010 2000088c 00000000 00009386 01000000 0040023b
20004860: 200048a8 00000010 2000088c 00000000 00009386 01000000 00403de4 00000000
20004880: 00000010 00000000 00000002 200036b8 2000088c 00000000 00009386 01000000
200048a0: 01000000 00000000 20003640 200048e0 20004908 00000000 00000000 20004908
200048c0: 00000010 00000000 20001680 00000f70 00000000 0040ead3 00000000 00000000
200048e0: 000f4240 02faf080 00000000 00000000 00000005 20001514 20001514 20001680
20004900: 00000000 0040344d 00000000 02faf080 00000008 00403683 00000000 00401b9d
20004920: 00000000 00000000 deadbeef 80000200 00000000 00000000 000000f0 80001010
R0: 00000002 200036b8 2000088c 00000000 2000088c 00000000 00009386 01000000
R8: 00403de4 00000000 00000010 00000000 00009386 200048a8 01000000 01000000
xPSR: 00000000 BASEPRI: 00000010 CONTROL: 00000000

I even went in to the serial driver interrupt handler and threw away all characters that weren't received on
the console port - same crash.

If I just exercise the TX side, I have the same issues, unless I send single characters with lots of space
between them. 

Any ideas?

Thanks,
--Bob

<*>Attachment(s) from bdoiron74@...:

<*> 2 of 2 File(s)
https://groups.yahoo.com/neo/groups/nuttx/attachments/2018907968;_ylc=X3oDMTJycGE2cHRnBF9TAzk3MzU5NzE0BGdycElkAzIzMzg5MDcwBGdycHNwSWQDMTcwNTAwNjU1OQRzZWMDYXR0YWNobWVudARzbGsDdmlld09uV2ViBHN0aW1lAzEzOTc1MDU5MjU- 
  <*> .config
  <*> log.txt

------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/nuttx/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/nuttx/join
    (Yahoo! ID required)

<*> To change settings via email:
    nuttx-digest@... 
    nuttx-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    nuttx-unsubscribe@...

<*> Your use of Yahoo Groups is subject to:
    https://info.yahoo.com/legal/us/yahoo/utos/terms/

Alexander Shiyan | 14 Apr 17:04 2014
Picon

Build troubles

Hello.

I decided to try to use the nuttx for some targets, but can not
build any working configuration ...

LD: nuttx
/usr/local/lib/gcc/arm-linux-gnueabi/4.7.3/libgcc.a(_dvmd_lnx.o): In function
`__aeabi_ldiv0':
/home/Extreme/tmp/arm-linux-gnueabi/libgcc/../../../gcc-4.7.3/libgcc/config/arm/lib1funcs.S:1328:
undefined reference to `raise'
/usr/local/lib/gcc/arm-linux-gnueabi/4.7.3/libgcc.a(_divdi3.o):(.ARM.exidx+0x0): undefined
reference to `__aeabi_unwind_cpp_pr0'
/usr/local/lib/gcc/arm-linux-gnueabi/4.7.3/libgcc.a(_udivdi3.o):(.ARM.exidx+0x0): undefined
reference to `__aeabi_unwind_cpp_pr0'
make[1]: *** [nuttx] Error 1
make[1]: Leaving directory `/home/git/nuttx-git/nuttx/arch/arm/src'
make: *** [pass2] Error 2

I am get same error for any other ARM target...
How to solve this problem?

PS: Gentoo x86_64, GCC 4.7.3 (works for all my other ARM stuffs: barebox,
kernel, uclibc, busybox, qt, etc...).

Thanks.
---

------------------------------------

Yahoo Groups Links

<*> To visit your group on the web, go to:
    http://groups.yahoo.com/group/nuttx/

<*> Your email settings:
    Individual Email | Traditional

<*> To change settings online go to:
    http://groups.yahoo.com/group/nuttx/join
    (Yahoo! ID required)

<*> To change settings via email:
    nuttx-digest@... 
    nuttx-fullfeatured@...

<*> To unsubscribe from this group, send an email to:
    nuttx-unsubscribe@...

<*> Your use of Yahoo Groups is subject to:
    https://info.yahoo.com/legal/us/yahoo/utos/terms/

lafleur | 14 Apr 17:52 2014
Picon

PIC32MX, PIC32MZ

Has there been any recent effort to build NuttX under MPLAB, XC32 tools now that there is a C++ compiler???

thanks...
lafleur  <at>   lafleur  .  us

__._,_.___


__,_._,___
spudarnia | 14 Apr 17:28 2014
Picon

Do Everything Script

I ran across this script on the net.  It seems to do everything with one command:  Download and built the tools and NuttX.

http://www.bkjia.com/xtzh/754116.html

__._,_.___


__,_._,___
pawel_999 | 13 Apr 03:20 2014
Picon

LPC1768 repeatable INVPC faul

Hi, I am running nuttx-6.33 on a LPC1768 based board(almost identical to the lpcxpresso) with a LAN8720 phy. The code is being compiled under native windows using gnu build tools version 4.8_2013q4. Target is being debugged using a segger jlink and eclipse. I am using this as a base for a small robotics project that I work on in my spare time.

I am basically running the nsh example based on the config in configs\lpcxpresso-lpc1768\nsh and the problem occurs every few minutes to every few hours. The fault signature is always the same. I commented out some of the code in the app to try and narrow this down since I have trouble understanding the fault source and have it reduced to the point where the application initializes the network driver, obtains an IP via dhcpc and then idles. Random experimentation revealed that if I run a fast ping to the board from my desktop the fault occurance will go up dramatically to just a matter of seconds after powerup. I used the fping tool for that. The fault dump and the referenced code at the alleged PC is located below. 

What I am wondering is if anyone has seen this before? I am not sure if this is a hardware issue, build tools or a problem with the driver/kernel so I am looking for any pointers on how to solve this mystery. I have been at it for many hours now and this is holding me up from actually having some fun :(

The only task I have running just sleeps for 5 seconds in a while loop and the fault always happens at the same PC location which actually straddles an instruction so that is odd unless I am reading this wrong. Here is my debug output from the serial console:
 
Initializing NSH
Successfully initialized SSP port 0
Successfuly bound SSP port 0 to MMC/SD slot 0
Initializing Networkup_hardfault:   PC: 79f2 INSN: df00
up_hardfault:   PC: 79f2 INSN: df00

up_hardfault:   PC: 79f2 INSN: df00
up_hardfault:   PC: 79f2 INSN: df00
up_hardfault:   PC: 79f2 INSN: df00
up_hardfault:   PC: 79f2 INSN: df00
up_hardfault:   PC: 79f2 INSN: df00
up_hardfault:   PC: 79f2 INSN: df00
up_hardfault:   PC: 79f2 INSN: df00
up_har dfault:   PC: 79f2 INSN: df00
up_hardfault:   PC: 79f2 INSN: df00
up_hardfault:   PC: 79f2 INSN: df00
up_hardfault:   PC: 79f2 INSN: df00
up_hardfault:   PC: 23c INSN: 8310
up_hardfault: Hard Fault:
up_hardfault:   IRQ: 3 regs: 10003508
up_hardfault:   BASEPRI: 00000000 PRIMASK: 00000001 IPSR: 00000003 CONTROL: 00000000
up_hardfault:   CFAULTS: 00040000 HFAULTS: 40000000 DFAULTS: 00000000 BFAULTADDR: e000ed38 AFAULTS: 00000000
up_hardfault:   R0: 0000000f 100000d8 10003598 00000000 3456abcd 3456abcd 12345678 1000359c
up_hardfault:   R8: 00000000 00000000 00000000 00000000 00000107 10003550 fffffff9 0000023e
up_hardfault:   xP SR: 0100300f PRIMASK: 00000000 (saved)
up_hardfault: PANIC!!! Hard fault: 40000000
Assertion failed at file:armv7-m/up_hardfault.c line: 185 task: Idle Task
sp:         10003440
stack base: 100035e4
stack size: 00000800
10003440: 00000107 00000000 10003450 00000b97 10003440 10000060 00000800 100035e4
10003460: 10003468 00000c2d 000000b9 0001464c 0001462c 10000060 10003498 00000e41
10003480: 00000000 00000000 00000107 10003550 fffffff9 0000023e 10003508 00000003
100034a0: 000134a8 00000000 00000003 00000001 00000000 83107e59 0000023c 10003508
100034c0: 00000019 3456abcd 3456abcd 12345678 100034d8 0000235d 10003508 00000003
100034e0: 100034e8 00000cc5 100034f0 0 0000337 10003508 00000003 2007dfb8 00000000
10003500: 1000359c 0000024b 10003550 00000000 3456abcd 3456abcd 12345678 1000359c
10003520: 00000000 00000000 00000000 00000000 0000000f 100000d8 10003598 00000000
10003540: 00000107 fffffff9 0000023e 0100300f 10003598 00000349 10003570 0000002c
10003560: 00000000 00000000 100035b8 0000024b 100035b8 00000000 00000000 100000d8
10003580: 00000001 00000000 00000107 000073a5 000073a4 01000200 1000359c 100000d8
100035a0: 10002b50 00000000 00000107 100035b4 00007203 100035bc 000016ed 100035c4
100035c0: 00004a18 100035e8 00000010 100035d4 000002f7 1000005c 00015aec 10005a80
100035e0: 1fff0d5f 100035c8 00000000 00000000 00000008 80000000 00000190 80000008
R0: 0000 000f 100000d8 10003598 00000000 3456abcd 3456abcd 12345678 1000359c
R8: 00000000 00000000 00000000 00000000 00000107 10003550 fffffff9 0000023e
xPSR: 0100300f PRIMASK: 00000000 CONTROL: 00000000

           lpc17_ritint:
00000204:    mov.w r0, #45   ; 0x2d
00000208:    b.w 0x234 <exception_common>
           lpc17_mcpwm:
0000020c:    mov.w r0, #46   ; 0x2e
00000210:    b.w 0x234 <exception_common>
           lpc17_qei:
00000214:    mov.w r0, #47   ; 0x2f
00000218:    b.w 0x234 < exception_common>
           lpc17_pll1:
0000021c:    mov.w r0, #48   ; 0x30
00000220:    b.w 0x234 <exception_common>
00000224:    mov.w r0, #49   ; 0x31
00000228:    b.w 0x234 <exception_common>
0000022c:    mov.w r0, #50   ; 0x32
00000230:    b.w 0x234 <exception_common>
00000234:    mov r2, sp
00000236:    add.w r2, r2, #32
0000023a:    mrs r3, PRIMASK
0000023e:    stmdb sp!, {r2, r3, r4, r5, r6, r7, r8, r9, r10, r11}
00000242:    cpsid i
00000244:    mov r1, sp
0 0000246:    bl 0x30c <up_doirq>
0000024a:    mov r1, sp
0000024c:    cmp r0, r1
0000024e:    beq.n 0x264 <exception_common+48>
00000250:    add.w r1, r0, #40       ; 0x28
00000254:    ldmia.w r1, {r4, r5, r6, r7, r8, r9, r10, r11}
00000258:    ldr r1, [r0, #0]
0000025a:    stmdb r1!, {r4, r5, r6, r7, r8, r9, r10, r11}
0000025e:    ldmia.w r0, {r2, r3, r4, r5, r6, r7, r8, r9, r10, r11}
00000262:    b.n 0x268 <exception_common+52>
00000264:    ldmia.w r1!, {r2, r3, r4, r5, r6, r7, r8, r9, r10, r11}
00000268:    msr MSP, r1
.........    ldr.w lr, [pc, #8]      ; 0x278 <exception_common+68>

Thanks,
Pawel


__._,_.___


__,_._,___

Gmane