<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic BME will be a hard fault in Kinetis Microcontrollers</title>
    <link>https://community.nxp.com/t5/Kinetis-Microcontrollers/BME-will-be-a-hard-fault/m-p/1417338#M62489</link>
    <description>&lt;P&gt;help me.&lt;/P&gt;&lt;P&gt;I am using KM34.&lt;BR /&gt;If you perform BME operation on port F as shown below, you will jump to a hard fault. Why?&lt;/P&gt;&lt;P&gt;Please let us know if you have a solution.&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;// #include "BME.h"&lt;BR /&gt;// #define BME_OPCODE_AND 1 / *! &amp;lt;AND opcode * /&lt;BR /&gt;// #define BME_OPCODE_OR 2 / *! &amp;lt;OR opcode * /&lt;BR /&gt;// # define BME_AND (ADDR) (* (volatile uint32_t *) (((uint32_t) ADDR) | (BME_OPCODE_AND &amp;lt;&amp;lt; 26)))&lt;BR /&gt;// #define BME_OR (ADDR) (* (volatile uint32_t *) (((uint32_t) ADDR) | (BME_OPCODE_OR &amp;lt;&amp;lt; 26)))&lt;BR /&gt;.&lt;BR /&gt;// # define GPIOE_BASE (0x400FF040u)&lt;BR /&gt;// #define GPIOE ((GPIO_Type *) GPIOE_BASE)&lt;BR /&gt;.&lt;BR /&gt;// # define GPIOF_BASE (0x400FF041u)&lt;BR /&gt;// #define GPIOF ((GPIO_Type *) GPIOF_BASE)&lt;/P&gt;&lt;P&gt;(BME_OR (&amp;amp; GPIOE-&amp;gt; PDOR) = (1u &amp;lt;&amp;lt; 3)); &amp;lt;-OK&lt;BR /&gt;(BME_AND (&amp;amp; GPIOE-&amp;gt; PDOR) = ~ (1u &amp;lt;&amp;lt; 3)); &amp;lt;-OK&lt;BR /&gt;(BME_AND (&amp;amp; GPIOF-&amp;gt; PDOR) = ~ (1u &amp;lt;&amp;lt; 5)); &amp;lt;-goto HardFault_Handler&lt;/P&gt;&lt;P&gt;thank you.&lt;/P&gt;</description>
    <pubDate>Tue, 22 Feb 2022 08:51:56 GMT</pubDate>
    <dc:creator>jun1</dc:creator>
    <dc:date>2022-02-22T08:51:56Z</dc:date>
    <item>
      <title>BME will be a hard fault</title>
      <link>https://community.nxp.com/t5/Kinetis-Microcontrollers/BME-will-be-a-hard-fault/m-p/1417338#M62489</link>
      <description>&lt;P&gt;help me.&lt;/P&gt;&lt;P&gt;I am using KM34.&lt;BR /&gt;If you perform BME operation on port F as shown below, you will jump to a hard fault. Why?&lt;/P&gt;&lt;P&gt;Please let us know if you have a solution.&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;// #include "BME.h"&lt;BR /&gt;// #define BME_OPCODE_AND 1 / *! &amp;lt;AND opcode * /&lt;BR /&gt;// #define BME_OPCODE_OR 2 / *! &amp;lt;OR opcode * /&lt;BR /&gt;// # define BME_AND (ADDR) (* (volatile uint32_t *) (((uint32_t) ADDR) | (BME_OPCODE_AND &amp;lt;&amp;lt; 26)))&lt;BR /&gt;// #define BME_OR (ADDR) (* (volatile uint32_t *) (((uint32_t) ADDR) | (BME_OPCODE_OR &amp;lt;&amp;lt; 26)))&lt;BR /&gt;.&lt;BR /&gt;// # define GPIOE_BASE (0x400FF040u)&lt;BR /&gt;// #define GPIOE ((GPIO_Type *) GPIOE_BASE)&lt;BR /&gt;.&lt;BR /&gt;// # define GPIOF_BASE (0x400FF041u)&lt;BR /&gt;// #define GPIOF ((GPIO_Type *) GPIOF_BASE)&lt;/P&gt;&lt;P&gt;(BME_OR (&amp;amp; GPIOE-&amp;gt; PDOR) = (1u &amp;lt;&amp;lt; 3)); &amp;lt;-OK&lt;BR /&gt;(BME_AND (&amp;amp; GPIOE-&amp;gt; PDOR) = ~ (1u &amp;lt;&amp;lt; 3)); &amp;lt;-OK&lt;BR /&gt;(BME_AND (&amp;amp; GPIOF-&amp;gt; PDOR) = ~ (1u &amp;lt;&amp;lt; 5)); &amp;lt;-goto HardFault_Handler&lt;/P&gt;&lt;P&gt;thank you.&lt;/P&gt;</description>
      <pubDate>Tue, 22 Feb 2022 08:51:56 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Kinetis-Microcontrollers/BME-will-be-a-hard-fault/m-p/1417338#M62489</guid>
      <dc:creator>jun1</dc:creator>
      <dc:date>2022-02-22T08:51:56Z</dc:date>
    </item>
    <item>
      <title>Re: BME will be a hard fault</title>
      <link>https://community.nxp.com/t5/Kinetis-Microcontrollers/BME-will-be-a-hard-fault/m-p/1417502#M62490</link>
      <description>&lt;P&gt;"&lt;SPAN&gt;// # define GPIOF_BASE (0x400FF041u)"&lt;BR /&gt;&lt;BR /&gt;It is unlikely that PORTF has a odd (vs even) address.&lt;BR /&gt;&lt;BR /&gt;Not sure if this is only an example or that the supplied headers are not being used.&lt;BR /&gt;Always best to use the supplied headers.&amp;nbsp; Alas they have been known to be wrong at times.&lt;BR /&gt;&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;&lt;BR /&gt;I assume the clock to PORTF was enabled as well.&lt;/SPAN&gt;&lt;/P&gt;&lt;P&gt;&lt;SPAN&gt;Also better to use UL as s suffix for portability, than just u.&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;/SPAN&gt;&lt;/P&gt;</description>
      <pubDate>Tue, 22 Feb 2022 13:05:44 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Kinetis-Microcontrollers/BME-will-be-a-hard-fault/m-p/1417502#M62490</guid>
      <dc:creator>bobpaddock</dc:creator>
      <dc:date>2022-02-22T13:05:44Z</dc:date>
    </item>
    <item>
      <title>Re: BME will be a hard fault</title>
      <link>https://community.nxp.com/t5/Kinetis-Microcontrollers/BME-will-be-a-hard-fault/m-p/1417774#M62492</link>
      <description>&lt;P&gt;Thank you for your teaching.&lt;/P&gt;&lt;P&gt;&lt;BR /&gt;I would be grateful if you could teach me three more points.&lt;BR /&gt;(1)&lt;BR /&gt;For GPIOF, I am using the attached MKM34Z7.h, which is on line 5446. Is this header wrong?&lt;/P&gt;&lt;P&gt;The CPU uses MKM34Z256VLL7.&lt;BR /&gt;/ ** Peripheral GPIOF base address * /&lt;BR /&gt;#define GPIOF_BASE (0x400FF041u)&lt;BR /&gt;/ ** Peripheral GPIOF base pointer * /&lt;/P&gt;&lt;P&gt;(2)&lt;BR /&gt;In the reference manual, there is the following table and the following sentences, but is it okay to use the address in (1)?&lt;/P&gt;&lt;P&gt;---&lt;/P&gt;&lt;P&gt;Kinetis KM34 Sub-Family Reference Manual, Rev. 3, 09/2017 -&amp;nbsp; &amp;nbsp;20.3.3 Additional details on decorated addresses and GPIO accesses&lt;BR /&gt;・・・&lt;BR /&gt;As a result, undecorated GPIO references and decorated AND, OR, XOR, LAC1 and&lt;BR /&gt;LAS1 operations can use the standard 0x400F_F000 base address, while decorated BFI&lt;BR /&gt;and UBFX operations must use the alternate 0x4000_F000 base address. Another&lt;BR /&gt;implementation can simply use 0x400F_F000 as the base address for all undecorated&lt;BR /&gt;GPIO accesses and 0x4000_F000 as the base address for all decorated accesses. Both&lt;BR /&gt;implementations are supported by the hardware.&lt;/P&gt;&lt;P&gt;---&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;(3)&lt;BR /&gt;The address for MBE is in the table, but the value corresponding to GPIO is unknown.&lt;BR /&gt;Please tell us some actual addresses of GPIOA to GPIOF.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Peripheral address space ： 0x4400_0000–0x4FFF_FFFF&lt;/P&gt;&lt;P&gt;Decorated AND, OR, XOR, LAC1, LAS1 references to peripherals and GPIO based at either 0x4000_F000 or 0x400F_F000&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Wed, 23 Feb 2022 01:21:26 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Kinetis-Microcontrollers/BME-will-be-a-hard-fault/m-p/1417774#M62492</guid>
      <dc:creator>jun1</dc:creator>
      <dc:date>2022-02-23T01:21:26Z</dc:date>
    </item>
    <item>
      <title>Re: BME will be a hard fault</title>
      <link>https://community.nxp.com/t5/Kinetis-Microcontrollers/BME-will-be-a-hard-fault/m-p/1418264#M62500</link>
      <description>&lt;P&gt;I do not have the header here to look at.&lt;BR /&gt;&lt;BR /&gt;The datasheet says "400F_F041 Port Data Output Register (GPIOF_PDOR)", which is different than GPIO base. So:&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN&gt;#define GPIOF_BASE (0x400FF041u)&lt;/SPAN&gt;&lt;BR /&gt;&lt;SPAN&gt;&amp;amp; GPIOF-&amp;gt; PDOR&lt;BR /&gt;&lt;BR /&gt;&lt;/SPAN&gt;is going to point to F041 + the offset of PDOR which is likely to be an invalid address.&lt;BR /&gt;Hard to say here as GPIOF may be different or same as GPIOF_BASE, not having the header at hand.&lt;BR /&gt;&lt;BR /&gt;PORTE probably works because it points to an address that is not invalid.&lt;BR /&gt;However it is not pointing to where you want to be.&lt;BR /&gt;&lt;BR /&gt;Try using &amp;amp;GPIOE_PDOR and &amp;amp;GPIOF_PDOR which would correspond to the PDOR addresses in the datasheet.&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;I did not see that the base addresses where given in the data sheet.&lt;BR /&gt;&lt;BR /&gt;Someone from NXP needs to clear up the discrepancy between the header and the datasheet.&lt;BR /&gt;&lt;BR /&gt;There is also this note in the Reverence Manual:&lt;BR /&gt;&lt;BR /&gt;&lt;SPAN class=""&gt;4.8.1 GPIO accessibility in the memory map&lt;BR /&gt;&lt;/SPAN&gt;&lt;SPAN class=""&gt;The GPIO is multi-ported and can be accessed directly by the core with zero wait states at&lt;BR /&gt;base address 0xF800_0000. It can also be accessed by the core and DMA masters&lt;BR /&gt;through the cross bar/AIPS interface at 0x400F_F000 and at an aliased slot (15) at&lt;BR /&gt;address 0x4000_F000. All BME operations to the GPIO space can be accomplished&lt;BR /&gt;referencing the aliased slot (15) at address 0x4000_F000. Only some of the BME&lt;BR /&gt;operations can be accomplished referencing GPIO at address 0x400F_F000.&lt;BR /&gt;&lt;BR /&gt;I really hate datasheets like this.&amp;nbsp; What does 'some' mean here?&amp;nbsp; We are left to guess...&lt;BR /&gt;&lt;BR /&gt;&lt;/SPAN&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;BR /&gt;&lt;/P&gt;</description>
      <pubDate>Wed, 23 Feb 2022 13:26:44 GMT</pubDate>
      <guid>https://community.nxp.com/t5/Kinetis-Microcontrollers/BME-will-be-a-hard-fault/m-p/1418264#M62500</guid>
      <dc:creator>bobpaddock</dc:creator>
      <dc:date>2022-02-23T13:26:44Z</dc:date>
    </item>
  </channel>
</rss>

